It shows up as five minutes spent writing a follow-up, 10 minutes rebuilding the status of a project, 20 minutes preparing an update, or half an hour turning a Jira report into a set of messages for the people who need to act on it. Each task is reasonable in isolation. Taken together, they can fill the day before the work that needs real attention has even begun.
I first noticed this pattern in my own role.
I was spending a large part of my time moving information between systems, checking whether work had an owner, chasing old tickets, preparing reports, building schedules, and translating the same context for different audiences. None of that was unimportant. It is part of running an engineering organization.
But a lot of it was procedural.
Once I started looking at it that way, AI became more interesting to me. Not as a replacement for management, and not mainly as a tool for generating prose. I began using it to take some of the friction out of the routines surrounding management.
A schedule was the first useful test
On-call scheduling is a good example because it appears simpler than it is.
A three-month rotation has to account for vacations, holidays, training, compensation days, prior assignments, weekend coverage, and a reasonable distribution of undesirable shifts. Creating a schedule manually meant holding all of those constraints in my head while working through possible combinations.
Now I provide the team roster, rotation history, and the rules for the schedule. Within seconds, I have a proposal to work from.
The task now has a different character. I no longer arrange names manually until the calendar looks acceptable. I review a schedule built around the constraints I care about.
The distinction may seem minor, but it has become one of the themes of how I work with AI: define the operating rules clearly, then let the system do the repetitive work of applying them.
The real savings come from connected work
The first obvious win was a schedule. The larger benefit appeared when I looked at routines that involved more than one system.
A critical Jira report, for example, can trigger a chain of small tasks. I need to identify the tickets that matter, find the appropriate engineer for each one, understand enough context to communicate clearly, and prepare a message. The wording may differ by person: one engineer may prefer English, another Spanish; a nickname may be appropriate in one case and a more formal tone in another.
I used to do that one message at a time. A review of the report could take around 30 minutes.
With Codex, I can provide the Jira information and the context that matters, then generate Slack-ready drafts tailored to each situation. The process now takes about a minute to prepare. More importantly, it removes a kind of work that is easy to overlook: manually carrying the same facts from Jira into several separate conversations.
The same effect shows up in project tracking.
For larger initiatives, I use a parent ticket to represent the project and subtasks to capture individual pieces of work. AI can help turn an initial plan into a usable set of trackable tasks. Later, it can consolidate the state of those subtasks into a status for the parent ticket.
A consolidated summary will not answer every question about a project. It gives me a faster starting point. Instead of opening 20 tasks simply to reconstruct the present state, I can begin with a coherent summary and direct my attention to the areas that are moving slowly, blocked, or unclear.
Executive reporting follows a similar path, although the inputs are broader. A useful summary may require information from Jira, incidents, Slack, emails, project updates, and meeting notes. The difficult part is rarely writing the update. It is assembling a trustworthy picture before writing it.
AI is particularly helpful at that stage. It can synthesize a large body of material into a structured view that I can interrogate, correct, and turn into an actual communication. What once took hours of gathering context is now much more focused.
The time savings are real, but the better outcome is that I spend more time interpreting the situation and less time collecting it.
Not every workflow begins with automation
The work that has taken the most care is the work that goes beyond drafting or summarizing.
I have created Codex skills to find unassigned tickets, highlight old tickets that need attention, and identify missed scheduled changes. These are useful because they act on rules I have defined, not because they make vague judgments about the team.
Getting there was gradual.
For the first couple of months, I reviewed the output closely. When the workflow produced an odd assignment or flagged something that did not deserve attention, I treated that as a problem with the rules—not as a reason to blindly trust or discard the tool. The logic improved through those iterations.
Only after the results became predictable did I become comfortable reducing the amount of manual checking.
Working this way changed how I think about automation. I no longer see the choice as doing everything manually or allowing a system to operate without limits. There is a middle ground in which a workflow can assist, recommend, and earn trust over time.
Most of the practical value sits in that middle ground.
Incident documentation is a different kind of problem
Incidents exposed another useful boundary.
After a significant event, the relevant record is rarely in one place. There may be Jira tickets, Slack conversations, monitoring data, change records, and notes captured during the response. Reconstructing a timeline means finding each relevant event and putting it into the right sequence.
Reconstructing the timeline takes time, especially when the incident is already competing for attention with recovery actions and follow-ups.
Codex can turn the available material into a proposed timeline and an initial RCA draft. The first draft matters because it gives the investigation a structure: an ordered set of events, an outline of what needs to be verified, and a document that can be improved instead of created from nothing.
The interesting part of this use case is not the draft itself. It is the separation between two kinds of effort.
One is organizing evidence. The other is deciding what that evidence means for the organization.
The first can be accelerated dramatically. The second requires engineering judgment, knowledge of the system, and accountability for the corrective actions that follow.
The line is about responsibility, not capability
There are areas where I do not want the tool making the decision, even if it has access to useful information.
Choosing between competing incidents, assessing whether an engineer is ready for promotion, delivering difficult performance feedback, or making a sensitive customer decision all require context that may not appear in tickets, chat histories, or dashboards. They also have consequences for people.
A manager cannot hand off the responsibility for those calls. I need to be able to explain the decision, stand behind it, and deal with its outcome.
I draw the practical boundary there.
AI is useful for organizing the evidence behind a decision and surfacing what deserves attention. Once the rules are clear, it can also carry out a defined process. The authority to decide, however, still belongs with the manager when the choice depends on relationships, values, trade-offs, or accountability.
The accumulated result
The small tasks are still there. Engineering management will always involve information: tickets, incidents, projects, staffing, communication, and planning.
What has changed is the amount of manual handling required before I can act on that information.
I no longer accept every repetitive sequence as a fixed cost of the job. When I find myself doing the same series of steps repeatedly, I look for the pattern. Sometimes it is too dependent on context to turn into a workflow. Often, though, there is a clear set of rules underneath it.
When that is true, AI can take on more of the execution than I would have expected.
The result is not an automated manager. It is more room for the work that benefits from an actual manager being present: career conversations, difficult technical discussions, preparation for escalations, clearer decisions, and time to think ahead rather than merely react.
AI's value lies in reducing the operational load around management and leaving more of the day for management itself.
