Lessons Learned

These are lessons that changed how I think — not refinements of existing beliefs, but genuine revisions. Each one required an experience that my prior model did not anticipate.

Adoption Depends on Friction, Not Merit

What happened

In 1992, I built Cutter — a Linux server accessible through familiar campus paths — at a time when Linux was technically capable but practically inaccessible. I did not campaign for Linux adoption. I built infrastructure that made trying Linux cost-free. Nearly 2,000 users reached Linux through Cutter, years before any institutional policy endorsed it.

What I believed before

Better technology wins because people rationally evaluate options and choose the superior one. Making the case for something better — through argument, demonstration, or documentation — is the mechanism of adoption.

What I believe now

Technology spreads when the cost of trying it drops below a threshold, not when the quality argument becomes conclusive. The adoption problem is almost always a friction problem. The argument is secondary. The access path is primary.

This has shaped every subsequent technology adoption effort: before explaining why something is better, ask what it would take for someone to try it inside their real workflow.

Advice to future leaders

Do not confuse persuasion with adoption. People who are persuaded but not enabled do not change behavior. People who are enabled — who encounter the thing inside a workflow they already trust — often adopt without needing to be persuaded at all. Reduce friction before increasing effort.

→ See also: Cutter: Democratizing Linux on Campus

Governance Can Accelerate Engineering

What happened

Working in regulated medical device software development, I encountered organizations where governance — documentation, review, traceability — was treated as overhead: a tax on engineering that slowed delivery without proportionate value. I also saw what happened when governance was built into the workflow rather than applied after it: review cycles shortened, submission preparation costs dropped, and engineers discovered defects earlier rather than later.

What I believed before

Governance and speed are in tension. More governance means slower delivery. Regulated environments accept this tradeoff because compliance is required. The goal is to minimize the governance burden while remaining compliant.

What I believe now

That framing is wrong — or at least, it only applies to episodic governance. Governance designed around retrospective evidence generation (document what you did, after you did it) is expensive and unreliable. Governance designed around continuous evidence generation (produce evidence as a byproduct of how you work) is neither expensive nor slow. It is faster than the alternative, because the cost of reconstructing evidence retrospectively is higher than the cost of generating it in real time.

The organizations that will move fastest in AI-assisted development are not the ones that eliminate governance. They are the ones that redesign governance for continuous generation.

Advice to future leaders

When someone says governance slows us down, ask whether they mean governance in general or the specific governance process they are experiencing. Almost always, the problem is episodic, retrospective governance — which can be redesigned. The answer is not less governance. It is governance that runs during the work rather than after it.

Building Is Easier Than Leading

What happened

Over a career that began in systems building and gradually shifted toward organizational leadership — creating engineering programs, establishing platform strategy, building cross-functional governance structures — I noticed a persistent pull: when things were uncertain or ambiguous, my instinct was to build something. Create a tool. Write a document. Propose an architecture.

The artifacts were often useful. They were also sometimes a substitute for the harder work of creating alignment, establishing ownership, or changing how people thought about a problem.

What I believed before

Technical leadership means applying technical solutions to organizational problems. If the organization isn't working, find what is broken and fix it.

What I believe now

At senior levels, the harder work is rarely the next artifact. Organizations change through people, relationships, shared language, aligned incentives, and sustained attention to the things that don't have completion dates. The builder's instinct — to create something concrete — can produce useful supporting artifacts, but it cannot substitute for the organizational work.

This is a lesson I am still learning. The pull toward building remains strong. The discipline is recognizing when what is needed is a conversation, not a deliverable.

Advice to future leaders

Notice when you are building to avoid leading. The artifact may be genuinely useful. It may also be a way of generating the feeling of progress while deferring the organizational work that only you can do. Both things can be true simultaneously.

→ See also: Principle 11 — Beyond the Prototype

Influence Is Often Invisible to the Influencer

What happened

At a social event, years after building the Remote Patron Authentication System for the Keystone Library Network, a young mother told me that being able to dial in to library resources after her baby fell asleep was what had allowed her to complete her master's degree. The RPAS had been, in her telling, a pivotal technology in her professional life. I had thought of it as an authentication system.

Separately: former students have told me, years after graduation, that a specific conversation — often one I do not clearly remember — changed how they approached engineering problems. The conversations that felt ordinary to me were pivotal to them.

What I believed before

Impact is proportional to effort and visibility. The projects that matter are the ones that get recognized. Influence flows from deliberate, high-profile contributions.

What I believe now

The most significant impact is often invisible to the person creating it. A tool that serves thousands of researchers. A conversation that changes one person's model of a problem. A course that gives someone the framework they will use for the rest of their career. These outcomes are rarely legible at the time.

The implication is that the ordinary work — the reliable system, the honest conversation, the careful course design — matters more than it appears to. And that the measure of a contribution cannot be determined by its recognition in the moment.

Advice to future leaders

Do the ordinary work with the same care as the work that will be recognized. You often cannot distinguish which is which at the time. The mother whose degree depended on an authentication system did not appear in any project retrospective.

Curiosity Compounds

What happened

A 1992 interest in Linux, maintained at the margins of a full teaching schedule, became an early open-systems deployment that gave thousands of students access to technology they would rely on for careers. An early interest in machine learning, developed through evenings and weekends while carrying a full faculty load, became research presented at AAAI and tools downloaded 20,000 times. A sustained interest in knowledge representation, pursued through a six-year self-funded Ph.D. alongside full-time employment, produced a doctoral dissertation and a methodology for epistemic honesty that has shaped every subsequent research and engineering decision.

None of these investments had immediate visible returns. All of them compounded significantly over time.

What I believed before

Professional investment is most effective when it is strategically directed: identify the skill that will be most valuable and develop it efficiently.

What I believe now

Strategic direction is valuable. But the most significant professional investments in my career were driven by genuine curiosity rather than strategic calculation. Curiosity sustains effort through phases where there is no external validation. It produces depth that strategic investment rarely achieves. And it tends to find unexpected applications — the ML work found its way into enrollment prediction before I knew enrollment prediction was a problem I would work on.

The compounding operates over long timeframes that are invisible to short-term planning. An interest maintained over a decade produces a fundamentally different level of insight than an interest pursued intensively for a year.

Advice to future leaders

Protect curiosity as an organizational resource. In your own work, maintain the exploratory threads that are not immediately justifiable. In organizations you lead, create space for people to develop deep interests that do not yet have an obvious application. The return is real but slow, and it will not appear in next quarter's metrics.

Entropy Always Wins Unless People Change

What happened

Across multiple institutional contexts — a university data system, a library network, an engineering curriculum, a platform architecture — I watched carefully built systems degrade when the people who understood them moved on. The systems continued to function, but the understanding of why they were built the way they were eroded. New contributors made local optimizations that were technically reasonable and architecturally damaging. Eventually the systems needed to be rebuilt from scratch by people who did not know they were recreating decisions their predecessors had already made and revised.

What I believed before

Good systems are self-documenting. Well-architected software communicates its own intent. The quality of the artifact is the quality of the transfer.

What I believe now

No artifact is self-explanatory at the level of intent. Code communicates what. Architecture communicates how. Only doctrine — explicit, maintained, taught — communicates why. And why is what new contributors need to maintain systems without degrading them.

The only durable change is capability embedded in people, practices, and doctrine. Software decays. Architectures are replaced. Organizations reorganize. What survives is understanding.

This is why I write doctrine. Not because the current principles are final, but because making them explicit gives them a chance to survive their author.

Advice to future leaders

Document the why, not just the what. Teach the reasoning, not just the conclusion. Build organizations where the doctrine survives the leader's departure — because it will be tested. The question is not whether entropy will arrive. It is whether the organization has enough embedded understanding to resist it.

The Cost of Intellectual Shortcuts Compounds

What happened

The Ph.D. work on OWL constraint generation required developing algorithms that were not just pragmatically useful but epistemically honest — that characterized their own uncertainty and supported retraction when evidence changed. This was harder than building systems that asserted confident conclusions. It was also slower, more expensive, and less immediately satisfying than approaches that produced clean answers.

But the method of thinking that it forced — grounding claims in evidence, maintaining honesty about what is not known, distinguishing confident conclusions from speculative ones — has shaped every subsequent research, teaching, and engineering decision in ways I could not have anticipated when the work was done.

What I believed before

Rigor is appropriate for research. Practical work often requires pragmatic shortcuts. The cost of intellectual precision is time, and time is usually the binding constraint.

What I believe now

Intellectual shortcuts produce intellectual debt. The interest rate is compounding and the payment often arrives at the worst time — in the middle of a regulatory review, when a system fails in a way that the shortcut made undiagnosable, when a decision must be made that requires understanding that the shortcut prevented developing.

Epistemic honesty — the discipline of knowing what you know, what you believe, and what you are speculating — is not just research integrity. It is practical engineering. Systems that know when they are uncertain are more useful than systems that are uniformly confident. Organizations that maintain epistemic honesty make better decisions than organizations that optimize for confident-sounding conclusions.

Advice to future leaders

The cost of rigor is visible. The cost of shortcuts is deferred and compounding. Account for both when making decisions about how much care to invest in work that will be built on by others.

→ Related: Patterns · Leadership · Engineering