There is a question I have returned to for most of my life: what helps people perform better over time?
At first, I asked it as an athlete. Training for endurance sport makes cause and effect unusually visible. The work is measurable, but never simple. More effort is not always better. A training plan has to account for adaptation, recovery, motivation, environment, and the athlete’s actual life. The result on race day is the visible edge of a much larger system.
Later, I asked the same question as an entrepreneur, an architect, a technology executive, and a solutions engineer. The vocabulary changed—platforms instead of training blocks, adoption instead of adaptation, operating models instead of race plans—but the underlying work did not.
Performance is a systems outcome
A good athlete rarely succeeds because of one exceptional workout. A good company rarely succeeds because of one exceptional feature. Durable performance comes from a system of reinforcing decisions: clear intent, useful feedback, disciplined execution, and the ability to adjust without losing direction.
That lesson became concrete while building TrainingPeaks. Athletes and coaches did not need another place to store numbers. They needed a shared environment for turning data into decisions. The product had to connect the plan, the completed work, the athlete’s response, and the coach’s judgment. Each part mattered because it changed what should happen next.
Growing Peaksware from a bootstrapped company also made the organizational version of that system visible. Product, partnerships, financing, distribution, and team design could not be optimized independently. Every meaningful decision changed the constraints on the others. Strategy was not a presentation about the future; it was the discipline of making those interdependencies useful.
Translation is infrastructure
In complex organizations, the most important gaps are often not technical. They are gaps between vocabularies.
Executives speak in terms of risk, growth, and market timing. Operators speak in terms of handoffs, exceptions, and capacity. Engineers speak in terms of interfaces, dependencies, and failure modes. Customers describe the world through the job they are trying to complete. None of these views is sufficient alone, and none is wrong.
Much of my career has been spent translating among them.
At Active.com, an internal sales platform had to support an organization changing almost by the week. At NantWorks, product roadmaps had to connect visionary healthcare ideas with the practical realities of software teams and commercialization. At Salesforce, a compelling healthcare solution has to make sense simultaneously to patients, members, clinicians, service teams, marketers, security leaders, and executives.
Translation is sometimes treated as a soft skill surrounding the real architecture. I have come to believe it is part of the architecture. Shared language determines whether a system can be understood, trusted, and changed.
Technology has to respect the operating truth
The cleanest diagram in the room is often the least accurate description of how work actually happens.
Every organization has an operating truth: the spreadsheets that bridge formal systems, the judgment calls that live only in someone’s memory, the customer exceptions that became permanent process, and the incentives that quietly shape behavior. Ignoring that truth does not make a transformation more ambitious. It makes the transformation brittle.
The first responsibility of a solutions architect is therefore not to prescribe. It is to observe well enough to understand the real constraint.
This is especially important in healthcare and life sciences. A connected experience is not valuable because data moved between two clouds. It is valuable because a member understood the next step, a patient received support at the right moment, a clinician spent less time reconstructing context, or a team could act with greater confidence. The human outcome is the architecture’s final test.
Build learning capacity
Plans matter. So does the ability to change them intelligently.
Endurance training works through feedback: stress, response, adaptation, adjustment. Product organizations work the same way when they are healthy. They form a view of the world, make an intervention, observe what happened, and refine both the product and the model behind it.
The best systems make that loop easier. They expose meaningful signals without pretending that data replaces judgment. They help teams distinguish a temporary deviation from a structural change. They preserve enough context that the next decision is better than the last.
That is why I increasingly evaluate technology by the learning capacity it creates. Can the organization see what is happening? Can the people closest to the work contribute what they know? Can leaders update direction without forcing the entire system into crisis? Can the customer feel the improvement?
The work continues
Endurance, entrepreneurship, healthcare, and enterprise technology can look like separate chapters on a résumé. For me, they are one continuous investigation into performance, systems, and human potential.
The most satisfying work has always happened at the intersections: business and technology, strategy and execution, data and judgment, ambition and patience. Those intersections are where translation matters, where architecture becomes tangible, and where a group of people can turn a difficult goal into a repeatable capability.
I built this site to write more about that work—what I have learned, what I am still testing, and where technology can create outcomes worthy of the effort it requires.
The through line is simple: build systems that help people make better decisions, do better work, and perform better over time.