Leadership

Leadership is creating an organization that no longer depends on you.

The Transition from Builder to Leader

Every engineer who moves into leadership faces the same disorientation:

Building creates progress, certainty, and control. When the code compiles, the system responds, the test passes — there is immediate evidence that something worked. The feedback loop is fast and legible.

Leadership creates ambiguity. You make a decision and wait weeks or months to learn whether it was correct. You invest in someone's development and the return arrives years later, in a conversation you are no longer part of. You build a doctrine and it outlasts the context that produced it.

The builder's instinct is to resolve ambiguity by building something. Create a tool. Document a process. Propose an architecture. The artifact is concrete proof that forward motion is happening.

At senior levels, this instinct can be counterproductive. The harder work is rarely the next artifact. It is the organizational work that no artifact can substitute for: creating alignment, establishing ownership, developing other leaders, changing how people think.

The transition is not from doing to not-doing. It is from making things to making the conditions under which others can make things.

Doctrine Over Process

Process tells people what to do.

Doctrine tells people how to think.

A process can be followed without understanding it. A doctrine requires understanding before it can be applied. That distinction matters enormously in situations the process did not anticipate — which is to say, in most interesting situations.

In fast-moving engineering contexts — new technology, regulatory change, market shifts — the specific steps of a process become obsolete faster than the principles that motivated them. A team that understands why the steps exist can adapt the steps to new conditions. A team that only knows the steps is stranded when conditions change.

This is why doctrine scales better than heroics. A heroic individual can carry institutional wisdom through a single transition. A doctrine carries it through every transition, including the ones that happen after the individual has moved on.

Building doctrine means:

Making principles explicit rather than leaving them implicit in how decisions are made
Explaining the reasoning behind commitments, not just the commitments themselves
Testing whether the doctrine is genuinely understood by watching what happens when the person who articulated it is not in the room
Revising doctrine when evidence contradicts it rather than defending it out of institutional inertia

Multiplying Technical Leaders

The leverage of senior technical leadership is not individual contribution. It is the development of other contributors.

This is not a management cliché. It is an engineering observation: the best technical work compounds when the people who did it can teach others to do it better than they did. The worst technical work extracts from its environment — producing artifacts that only the original contributor can maintain, making the organization more dependent rather than more capable.

Multiplying technical leaders requires specific practices:

Give ownership early. Waiting until someone is fully ready is usually waiting too long. Leadership capability develops in the context of genuine responsibility, not in the context of supervised simulation. The cost of earlier-than-optimal ownership is bounded. The cost of delayed ownership is loss of the development window.

Create space for failure at the right scale. Technical leaders need to encounter failure while the stakes are recoverable. Protecting someone from failure entirely prevents the development of judgment that failure produces. Exposing them to failure at stakes that cannot be recovered is destructive. The leader's job is calibrating that range.

Explain reasoning, not just conclusions. If a senior leader always provides conclusions without showing reasoning, direct reports learn to defer rather than to think. Showing the reasoning — including the uncertainty, the tradeoffs considered and rejected, the things that could go wrong — builds the capacity to reason independently.

Make expertise visible. Engineers often underestimate the value of their own knowledge because they have internalized it. Making expertise visible — in documentation, in teaching, in articulated doctrine — converts tacit knowledge into shared capability.

Protecting Early Adopters

Every major technology transition produces early adopters — people who see what is coming before the institution has a framework for it, who push past resistance through personal conviction, and who are often dismissed as impractical or naïve until the moment they are not.

Leaders have a specific responsibility to these people.

The early adopter generates a signal. The leader's job is to determine whether that signal represents noise or a leading edge — and then to protect it long enough to find out.

Protecting it means:

Advocating for experimentation budget before results exist
Absorbing institutional skepticism on behalf of someone else's work
Creating governance exceptions for genuine exploration without abandoning governance entirely
Recognizing that being wrong occasionally is the price of being early

Organizations that suppress early adopters do not eliminate the signal. They eliminate the ability to receive it.

The institutional immune responses — budget controls, change management processes, security reviews, vendor approval chains — are not inherently wrong. They exist for legitimate reasons. But when applied uniformly, without any valve for exploration, they eliminate precisely the signal that would allow the organization to adapt.

The question is not whether early adopters exist in your organization. They always do. The question is whether the organization has created conditions in which their work can survive long enough to generate evidence.

Teaching Executives

Teaching executives requires a different approach than teaching engineers.

Engineers evaluate claims by asking whether they are technically correct. They tolerate ambiguity if the technical argument is sound.

Executives evaluate claims by asking whether they are strategically useful. They have less tolerance for technical ambiguity and more tolerance for strategic uncertainty. They reason from analogies to situations they have already navigated, not from first principles in a domain they have not inhabited.

This creates a translation problem. The technically correct presentation of a platform strategy — with cost models, component diagrams, and traceability matrices — may be less persuasive than the strategically framed version: what decision does this platform enable that you cannot make today? What risk does it reduce? What is the cost of not building it?

Neither framing is dishonest. They are different entry points into the same truth, appropriate for audiences with different priors and different decision frameworks.

Knowing which framing to use — and being able to move between them in the same conversation — is a specific leadership skill. It requires genuine understanding of both domains: enough technical depth to know what matters, enough strategic fluency to explain why it matters to someone who is not going to build it.

Working across disciplines requires the same translation capacity: from software to systems engineering, from engineering to quality and regulatory, from technical to clinical, from inside the organization to outside it. Each boundary requires adapting the framing without sacrificing the substance.

Creating Ownership

Reuse without ownership becomes dependency.

Ownership does not mean control. It means responsibility: for the quality of the asset, for its fitness for purpose, for the consequences when it fails, and for the investment required to keep it useful over time.

Assigning ownership is the hardest part of platform design — harder than the technical architecture, because it requires aligning incentives across people and teams with different goals, timelines, and accountability structures.

The organizational failure modes:

Phantom ownership. Everyone nominally owns the shared asset. When it breaks, nobody fixes it. When it needs investment, nobody funds it. The asset degrades.

Monopoly ownership. One team owns the shared asset. Every other team depends on that team's priorities, capacity, and willingness to serve others' needs. The asset becomes a bottleneck.

Absentee ownership. The asset is assigned to a team that did not choose it, does not understand it, and has no incentive to improve it. The asset stagnates.

Real ownership requires:

An explicit mandate, not just an implicit expectation
Resources sufficient to meet the mandate
Accountability for the outcomes that depend on the asset
Genuine understanding of what the asset needs to remain healthy

Creating real ownership is fundamentally a leadership task. It requires organizational design, not just technical design.

Organizational Change Takes Longer Than Engineering

A recurring observation across every significant project: the technical work is never the constraint.

The enrollment data warehouse was built before Academic Affairs trusted the data enough to use it. The medical device platform architecture was clear before the cross-functional ownership model existed to sustain it. The engineering programs at Shippensburg were curricularily ready years before the Board of Governors approved them.

In each case, the organizing principle holds:

Governance takes longer than engineering. Culture takes longer than governance. Identity takes longer than culture.

The technical architecture can be drawn in days. Building the human infrastructure — the shared language, the aligned incentives, the distributed ownership, the mutual trust — takes years.

Leaders who understand this sequence make a different set of investments. They invest early in relationship-building, not just in technical design. They create shared language before they need it for a specific decision. They establish credibility through demonstrated accuracy before introducing claims that challenge existing belief.

The ROI on social infrastructure often appears in crisis, not in normal operations — when trust is needed quickly, in a situation that nobody anticipated. Organizations that built it early can move. Organizations that did not find themselves in negotiation at exactly the moment when speed matters most.

What Success Looks Like

Success is leaving an organization more capable than it was when you arrived.

Not because of the software written.

Not because of the programs created or the tools built or the papers published.

Because the people, systems, and ideas continue improving after you leave.

That definition is easy to state and hard to operationalize. It requires letting go of credit. It requires building systems that function when you are not present. It requires developing people who will exceed your own contributions. It requires doctrine that survives its author.

The builder's instinct is to create something that bears your signature. The leader's aspiration is to create something that no longer needs it.

→ Related: Patterns · Engineering · Lessons Learned