Understanding the technology is part of serving the people responsible for delivering it

I have never believed that a project manager needs to be the best engineer in the room. In fact, trying to be can undermine one of the most important responsibilities of project leadership: creating an environment in which the people with the appropriate expertise can succeed.

I do believe, however, that technology leaders have an obligation to understand the systems, constraints, risks, and engineering disciplines behind the work they are responsible for delivering.

For me, those two ideas are closely connected.

Technical understanding makes me a better servant leader.

A project manager cannot effectively remove impediments, challenge unrealistic expectations, protect a team from unnecessary disruption, facilitate sound decisions, or communicate accurately with executives without understanding enough about the underlying work to recognize what the team actually needs.

That philosophy has shaped much of my career.

I have spent decades working at the intersection of business, technology, operations, governance, and execution. Whether an initiative involved PeopleSoft financial systems, enterprise reporting, data integration, workflow automation, operational resiliency, cybersecurity, NLP, or enterprise transformation, I have always wanted to understand what was happening beneath the project plan.

A schedule tells me when something is supposed to happen.

A status report tells me what people believe is happening.

Understanding the technology helps me determine why something is happening, what could prevent it from happening, and what I can do as a leader to help the people doing the work succeed.

That becomes particularly important with artificial intelligence.

AI Changes the Leadership Problem

Enterprise AI is frequently discussed as a technology adoption problem: select a model, identify use cases, establish governance, train employees, measure adoption, and scale successful implementations.

Those things matter. But they do not fully explain what happens when AI becomes an active participant in knowledge work and software engineering.

AI can dramatically increase development velocity. It can analyze requirements, generate code, propose architectures, create tests, diagnose failures, produce documentation, and coordinate increasingly sophisticated workflows.

That acceleration creates an important management question:

How do you gain the speed and capability of AI without surrendering architecture, quality, governance, evidence, accountability, or human judgment?

It also creates a leadership question:

How does a project manager support teams operating in this environment without becoming either an uninformed administrator or an unnecessary technical authority?

I believe servant leadership provides part of the answer.

The project manager does not need to become the architect or engineer. The project manager needs sufficient understanding to listen intelligently, recognize constraints, facilitate decisions, remove impediments, protect engineering integrity, and ensure that organizational pressures do not force teams into avoidable technical compromises.

I did not want my understanding of those responsibilities to remain theoretical.

When my most recent enterprise engagement ended, I had an unusual opportunity: time.

I decided to use it deliberately.

Rather than simply studying AI transformation from the management layer, I wanted to experience the problem from the engineering layer upward. I wanted firsthand exposure to the capabilities, limitations, failure modes, governance requirements, and operational implications of AI-assisted development.

That decision ultimately produced three interconnected bodies of work: the Engineering System (ES), the Personal Operating Environment (POE), and the Phronesis Platform.

Engineering System: Establishing the Discipline

The Engineering System began with a relatively straightforward observation.

AI can produce software remarkably quickly.

Speed, however, is not the same thing as engineering.

Enterprise software development still requires architecture, requirements, boundaries, testing, evidence, traceability, quality controls, exception management, documentation, and accountable decision-making. Increasing development velocity does not eliminate those requirements. In many respects, it makes them more important.

I therefore developed the Engineering System as an architecture-first framework for governed AI-assisted software engineering.

Its central principle is deliberately simple:

AI may accelerate the engineering process without becoming the authority over the engineering process.

The system establishes boundaries for AI authority while retaining accountable human control over objectives, architecture, risk acceptance, exceptions, quality standards, and final approval. Automated verification, quality gates, retained lifecycle evidence, and certification provide objective evidence that the resulting system behaves as intended.

There is a servant-leadership principle embedded in that architecture as well.

Governance should enable people to work effectively, not simply impose controls upon them.

Good governance establishes clear boundaries so that teams understand where they have autonomy, where decisions require escalation, what constitutes acceptable evidence, and how success will be evaluated. It reduces ambiguity rather than creating bureaucracy.

The same principle applies to project leadership.

My role is not to make every decision. My role is to help create the conditions in which the right decisions can be made by the right people with the right information.

But a governance framework written on paper proves very little.

I needed to know whether mine actually worked.

Personal Operating Environment: Proving the System

That requirement led to the Personal Operating Environment (POE) Backup Orchestrator.

POE was not created merely because I needed another software application. It became the proving ground for the Engineering System.

I deliberately took a real engineering problem through a phased development lifecycle using the controls and disciplines I had established. Requirements became architecture. Architecture constrained implementation. AI assisted development within defined boundaries. Automated testing and verification challenged the implementation. Evidence was retained. Failures resulted in correction rather than assumption.

The project ultimately became a practical demonstration of something much more important than the backup functionality itself.

At its current certification milestone, POE has achieved 1,075 passing automated tests.

That number matters, but not because test count is itself the objective. It represents accumulated evidence that AI-assisted engineering can be subjected to deterministic verification, regression protection, architectural constraints, quality gates, and accountable human oversight.

The Engineering System establishes the standard.

POE proves that the standard can operate in practice.

It also gave me something that I consider important as a servant leader: greater empathy for the people performing the work.

There is a significant difference between intellectually understanding that a requirement is ambiguous and experiencing the downstream consequences of that ambiguity. There is a difference between discussing technical debt in a status meeting and watching an expedient implementation create problems several stages later. There is a difference between asking why testing takes time and seeing how seemingly minor changes can introduce regression risk across an interconnected system.

That experience changes the questions a project manager asks.

It also changes how quickly that project manager is willing to impose an answer.

Phronesis: Moving From Proof Toward Enterprise Scale

The next question was inevitable.

If governed AI can participate effectively in a controlled engineering environment, how might those same principles apply to broader enterprise operations?

That is the direction of Phronesis.

Phronesis is an evolving modular AI-enabled operational intelligence platform exploring how enterprise information, persistent knowledge, AI reasoning, workflow orchestration, automation, governance, and human decision-making can be connected.

The objective is not autonomous AI for its own sake.

It is the transformation of information into increasingly useful organizational capability:

Information → Knowledge → Understanding → Action

That progression also represents the larger reason I undertook this work.

Servant Leadership Requires More Than Being Supportive

Servant leadership is sometimes reduced to being agreeable, accommodating, or simply asking a team, “What can I do to help?”

I see it differently.

In complex technology programs, serving the team requires enough understanding to make that question meaningful.

If an architect tells me a proposed shortcut creates unacceptable coupling, I should understand enough to explore the implications.

If an engineer identifies technical debt that threatens future delivery, I should be capable of distinguishing a legitimate engineering concern from ordinary implementation preference.

If testing identifies a systemic problem, my first reaction should not be to ask how quickly the team can close the defect so the milestone remains green.

And if an executive asks why something cannot simply be delivered two weeks earlier, I need enough technical understanding to explain the consequences rather than transferring the pressure directly to the engineering team.

That is where technical understanding and servant leadership intersect.

The PM becomes a translator, facilitator, advocate, and integrator—not a substitute for the experts.

Sometimes serving the organization means challenging the team.

Sometimes serving the team means challenging the organization.

The project manager needs enough understanding to know when each is appropriate.

Technical Understanding Improves the Quality of Leadership

Building these systems forced me to confront questions that look very different when encountered in an operating system rather than on a presentation slide.

What happens when an AI agent misunderstands a requirement?

How much context is enough?

What should persist between interactions?

Where should AI authority end?

How do you prevent a fast-moving implementation from violating its architecture?

What constitutes sufficient evidence?

How do you know a change has not damaged something elsewhere?

When should automation stop and request human judgment?

How do you preserve accountability when machines perform an increasing percentage of the work?

These are engineering questions.

They are also enterprise AI leadership questions.

And understanding them changes how I interact with technical teams.

I can ask better questions without pretending to have all the answers. I can recognize when an engineer needs an impediment removed rather than another status meeting. I can translate technical constraints into business consequences. I can protect appropriate engineering discipline while still holding teams accountable for outcomes.

Most importantly, I can give specialists room to exercise their expertise because I understand enough about the work to know where my authority should—and should not—extend.

That, to me, is an important element of servant leadership.

The Project Manager I Want Managing AI

I did not spend the period between enterprise engagements trying to become a full-time software engineer.

I spent it becoming a better technology leader.

A project manager does not need to write every line of code to lead engineers effectively, just as a construction project manager does not need to personally install every electrical circuit.

But leadership becomes substantially stronger when the person accountable for execution understands the underlying work well enough to challenge assumptions, recognize dependencies, understand risk, ask technically credible questions, and distinguish genuine progress from optimistic reporting.

And servant leadership becomes stronger when that understanding is used not to control specialists, but to enable them.

My responsibility is to establish clarity around objectives, facilitate decisions, remove obstacles, protect appropriate governance, communicate reality upward, and ensure that the people closest to the work have the information and organizational support necessary to perform it well.

Technical literacy makes me better equipped to do those things.

Using the Space Between Engagements Deliberately

There is another reason I believe this work belongs prominently on my professional website.

Time between engagements does not have to represent a gap in professional development.

I chose to treat mine as an opportunity to invest in the next stage of my career.

I earned the PMI Certified Professional in Managing AI (PMI-CPMAI) credential. I expanded my study of enterprise AI adoption and governance.

More importantly, I built.

The Engineering System gave me a governance model.

The Personal Operating Environment gave me empirical evidence.

Phronesis is giving me a platform through which to explore what comes next.

Together, they have allowed me to examine enterprise AI adoption from multiple perspectives: executive governance, program management, architecture, engineering, testing, operationalization, knowledge management, automation, and human accountability.

They have also reinforced something I already believed about leadership.

The closer I can get to understanding the work, the better equipped I am to serve the people doing it.

That experience will influence how I lead my next enterprise AI initiative.

When engineers discuss architecture, I want to understand the implications.

When governance teams discuss controls, I want to understand what those controls mean operationally.

When executives discuss AI velocity, I want to understand the corresponding risks.

When a team reports that an AI-enabled capability is ready, I want to know what evidence supports that conclusion.

And when specialists need someone to remove an organizational obstacle, defend a sound technical decision, resolve an ambiguity, or translate their concerns into language executive stakeholders can act upon, I want to be capable of doing that effectively.

Because ultimately, I do not believe the project manager exists so the team can serve the project manager.

The project manager exists to create the conditions in which the team can successfully serve the objective.

And when I am accountable for leading enterprise AI transformation, I want that leadership grounded in more than schedules, dashboards, and governance meetings.

I want it grounded in technical understanding, informed judgment, accountable execution—and the ability to serve the people I am asking to deliver the outcome.