Then I find the problem that matters, design something practical, and work across business and technical teams until it is running and people are using it. Seven years doing that inside a highly regulated commercial aerospace environment.
Each of these started the same way: an environment I did not yet understand, a problem nobody had defined cleanly, and a set of people who knew something I needed to learn. Descriptions are kept at a business level.
Publication planning for engineering changes ran across 10 commercial engine programs with no shared view of status. Planners tracked work in spreadsheets and email, and the same questions were answered again by hand every week.
I sat with planners across the programs and mapped how a change actually moved from engineering release through to published content. I documented where information was re-entered, where status was ambiguous, and which decisions were sitting idle waiting on someone else's file.
The constraint was not effort or headcount. It was the absence of a single current-state view. Work looped back on itself because nobody could see status without asking someone.
I defined a planning and workflow application that held engineering-change data as one record, with status, ownership and sequencing visible to every program at once.
I wrote the requirements and scope, coordinated an external developer through the build, ran testing and UAT with the planners who would use it, then supported rollout and adoption across all 10 programs.
Manual workflow loops down 85%. Planning decision time down 30%. It is now the standard planning system across the programs it supports.
Distribution of technical publications ran across several functions, suppliers and approval steps. There was no single owner of the end-to-end process and no consistent way it was carried out between programs.
I mapped how the work actually moved across users, systems, suppliers, approvals and stakeholders, rather than how the documented process said it moved. That meant interviewing each group and following real cases through to completion.
Delay clustered where ownership was unclear and where approvals had no defined gate. Inconsistent handoffs, not capacity, drove most of the variation between programs.
A future-state operating model: defined workflows, a named owner at each stage, explicit approval gates, control points, lifecycle visibility and the performance measures to tell whether it is working.
I am working across the Customer Service organization and partner functions to agree the model, stand up the supporting tooling and reporting, and build in a mechanism for continuous improvement.
In progress. Delivered so far: documented current state, an agreed future-state workflow, an ownership map and a measurement framework spanning all 10 programs.
Requests moved between Customer Technical Services and Technical Publications by email, in no fixed format, with no agreement on what information a request needed to contain.
I traced a sample of requests end to end and talked to both sides separately about what they needed to receive versus what they were actually getting.
Most of the delay was rework. Requests arrived missing the fields the receiving team needed, so nearly every one triggered a clarification cycle before any work could start.
Standardized intake. I defined the information required up front, built a structured digital intake and routing path, and set explicit handoff points between the two organizations.
I agreed the format with both organizations, piloted it on live requests, adjusted based on what the pilot exposed, then moved it to standard use across the engine programs.
Processing speed improved 43%. Requests now arrive complete rather than starting a round of clarification.
Leadership and program teams had limited visibility into throughput, backlog and delivery risk. Status arrived through manual reporting that was out of date by the time it was read.
I worked with operational data covering more than 2,500 documentation changes to understand what the records could genuinely answer, and asked the teams which decisions they were making without data in front of them.
The questions that mattered were operational rather than historical: what is at risk this week, where is backlog building, and do we have the capacity to absorb what is coming.
Power BI dashboards and a reporting cadence built around throughput, turnaround time, backlog, capacity, delivery status and risk, rather than reporting for its own sake.
I replaced the manual status process with the dashboards and worked with the teams so the data became part of the weekly operating rhythm instead of a separate exercise.
Decisions now run on current data, and the reporting effort came off the teams doing the work.
There was no way to state with confidence that every engineering change going back to 2017 had been incorporated into published content.
I reconciled the engineering-change record set against incorporation data in the product lifecycle system of record, change by change, back to 2017.
What looked like a backlog question was really a control question. Nothing in the process would surface a missed change close to when it happened, so any gap could sit undetected indefinitely.
Complete the reconciliation, then convert the one-time analysis into a recurring control with defined exception logic rather than leaving it as a finished project.
I set the exception criteria and review cadence with the team that would own it going forward, so the control runs without me.
Full reconciliation with zero missed changes. Exceptions now surface within three to four weeks instead of being found later by audit.
Outsourced service delivery across a $5M+ services portfolio and 20+ global suppliers, covering statements of work, delivery cadence, performance reviews, escalation and capacity planning.
Budget ownership for outsourced services, plus monthly planned versus actual review across a broader program portfolio, communicating variance, capacity and delivery risk to leadership.
Most failed changes are not failures of execution. They are failures of diagnosis.
Follow how information, decisions and ownership actually move between people. The documented process and the real one are rarely the same, and the gap between them is usually where the problem lives.
The visible problem is usually downstream of the real one. The question worth answering is where the process, the data, the system or the ownership actually breaks down.
A workflow that ignores how the team really operates will not survive the first week after launch. Practical beats elegant.
Working across business stakeholders, developers, suppliers and users through build, testing and rollout is where most of the value is either won or lost.
Cycle time, backlog, rework, decision speed. If none of them moved, the diagnosis was wrong and it is worth saying so.
AI is most useful when it helps teams work faster and more clearly without introducing unnecessary complexity.
The clearest use cases are repetitive tasks that slow people down. Drafting emails, summarizing notes, organizing information, and preparing first pass outputs can create immediate value and free people to focus on judgment and customer interaction.
In larger organizations, I see more value in role specific workflows with a human in the loop than in expecting every individual to invent their own AI habits. A workflow that drafts the message and lets the user review it can be more consistent, scalable, and easier to govern.
For a small startup, an enterprise deployment of ChatGPT or Claude may be enough to unlock value quickly. In a larger company, more structured solutions often make more sense because governance, consistency, and adoption matter just as much as the model itself.
I have spent more than seven years at Pratt and Whitney across supplier governance, engineering change operations, finance, digital workflows and cross functional program delivery. Most of that time has been spent walking into processes I did not yet understand and working out how they actually run.
I work between the business and the technical side. I can hold the requirements, data, testing and rollout conversation, and I know enough to ask a developer the right questions. The engineering is done by engineers. My job is making sure they are building the right thing, and that it gets used once it exists.
I am especially interested in how AI and emerging technology change that equation, when they are paired with a real understanding of the process underneath.
Pratt and Whitney. Supplier portfolio, financial management, engineering change execution, and business transformation.
Pratt and Whitney. Business side software implementation, workflow improvement, and operational controls.
Pratt and Whitney. Analytics, documentation workflows, and program coordination.
University of Connecticut.
University of Connecticut. Business and engineering education.
If you are working on something complicated and not yet well defined, in operations, transformation, implementation or product operations, I would enjoy the conversation.