# Career — Level 3

## Overview

An engineering leader with 30 years of work experience spanning the full depth of software systems and product development: distributed architecture, technical implementation, product design, user interaction design, testing, process, organizational leadership, program management, and product management. I operate across these domains as a systems thinker, rather than as a generalist, understanding how each layer affects the others. The central driver of my work has always been a single question: how do you make it easy for teams to do the right thing? That question drew me horizontally, outward from technical implementation into adjacent domains that shape how software gets built. Each expansion was deliberate. Each one made the next more effective.

## How I Lead

I lead at the level of the work, as well as at the level of the product and strategy. Continuity is a primary concern: a team's capacity to deliver continuously without interruption is the measure. I encourage teams I lead to make their own values and norms explicit — not values handed down — and review them continuously. I work to make the whole team aware of the entirety of the work through situational awareness, both to create opportunities for efficiency and to lower integration costs and missed targets. I lead by example. I learn some of the work of every role, not to match specialist depth, but to deepen my respect for what they bring.

I've started many products from scratch, joined mature and established product teams and projects, and led modernization of legacy products in equal measure. I've coached people at every level of the organization, from juniors to executives, both in my staff roles and in consulting. The two recurring scenarios are business leaders moving into product development for the first time, and leaders trying to understand why their product engineering efforts aren't meeting their expectations.

I have fluency across numerous process models, including Lean, Agile, phase-gate, and others not so well known. My motto is "specific countermeasures for specific circumstances." I often ask the clarifying questions, "What problem does that solve?" and "How does that solve the problem?" I lean on process principles, applying particular practices where they're most needed or best suited, flowing between methodologies as the work requires. I customize processes in concert with individual contributors, so the process stays workable for them rather than imposed on them. I encourage teams and engineers to surface mistakes so that they can be treated purely as improvement opportunities.

## Origins and Practice

I started my career in 1991 as an independent contractor for Zep Manufacturing, a manufacturer of consumer and industrial products. I built the chemical product manufacturing system used in their three Canadian factories. I was re-engaged three years later to rebuild the system for a new operating system and a new GUI. Those early engagements established a pattern that has defined my career: high-trust, high-autonomy work where I owned the problem end to end. Across consulting practice, in-house engineering leadership, and startup work over three decades, I've worked in retail, finance, manufacturing, national defense, data center operations, CRM, social media, education, event management, and legal technology, with clients including Capital One, Microsoft, Rackspace, Baker-Hughes, Chevron, Fannie Mae, the Mexican Trade Delegation, Canadian National Defense Headquarters (NDHQ), VersionOne, and TheKnot.com.

## Path to Distributed Systems

My exploration of messaging systems began at a CRM company in 2007. I led a team of ten through a litigation-forced product pivot from zero to beta, researching messaging middleware as the integration approach our customers would use. At Rackspace from 2011 to 2012, I built an eight-person Austin expansion team for the global data center automation group. I led the architectural initiative to migrate 22 tightly-coupled legacy web applications toward an evented, message-driven architecture, designing the target system, building proofs of concept including legacy integration, and coaching the team on distributed systems design principles. That work became the direct foundation for the Eventide Project. As CTO of Aptus Technologies from 2012 to 2013, I led a full product recovery for a security intelligence platform serving military, law enforcement, and security professionals. I assembled a new team from scratch and took the product from a non-viable offshore codebase to an operational first increment in six months.

## Eventide Project

I'm the founder and principal author of the Eventide Project and Message DB, an open-source framework and event store for event-sourced, message-driven systems active since 2014 and recognized with the Fukuoka Ruby Award for Social Impact. I've authored 72% of the codebase while building a practitioner community through workshops, training, and direct team support. I authored the project's documentation, including the Doctrine of Useful Objects, which establishes the project's structural design style guide. It emphasizes behavioral over data-centric components, single-purpose units, and testability through telemetry rather than intrusive mocks and stubs. I designed Eventide for autonomous components that communicate through explicit message flows, with clear architectural boundaries and predictable patterns for how systems evolve over time. The project is currently entering its next generation, the last in which I'll be making significant implementation contributions, as we integrate more generative AI into the work. I'm mentoring two engineers as my successors on the project, with the goal of handing off to the next generation of leaders this year.

## Recent Work: Fast Company-Recognized Platform at Global Law Firm

Most recently I spent five years with a global law firm, a traditional business environment with no prior software product experience. Starting with two technologists and two business leaders, I co-led the growth of the product organization to thirty people, serving as principal architect, principal engineer, process leader, and tooling author. The organization included twenty engineers and ten in product operations, subject matter expertise, and management. The same process principles I applied to the engineering side gave the non-engineering side comparable structure, flow, and continuity. I brought the architecture, the open source tooling, the process methodology, and the organizational model. I integrated designers and engineers into shared work cells, eliminating the handoffs that fracture most product teams. I introduced lean practices rooted in the Toyota Product Development System to both technical and business leadership, an organizational transformation that required sustained patience, demonstrated results, and ultimately produced a leadership team capable of carrying the approach forward independently. I advised the company on its establishment of its product support and product operations functions. The platform spans a dozen web applications and over 100 backend components, automating key legal workflows across the firm's emerging companies and venture capital practice from incorporation to IPO. It earned the firm a place on Fast Company's World's Most Innovative Companies list. The platform and team continue to grow.

## Design Philosophy

My purpose in design is developer experience and developer productivity. It's the same for user experience and user productivity. Whether applied to structural design or user interface design, it's the same concern appearing in different areas of the work. The structural decisions I make — coupling, compartmentalization, telemetry, the design hierarchy — all serve that purpose. The connection to continuity is direct: productivity is only sustainable when work can continue without interruption, and continuity is what design either enables or breaks.

Structural design principles approximate a science of design, even offering some ability to be measured when appropriate. They lend a degree of objectivity to unclear decisions that rest on subtle differences. Tribal knowledge is critical to understanding the current state of a system. Design principles guide the conversation about what to do next. Design principles are learnable and concrete, and not a mystery.

On a productivity balance sheet, proven work is an asset. Unproven work is liability. It's risky to see it as a foundation for further work. It's akin to inventory in production systems: invisible until the moment it breaks continuity.

I appreciate designs that emit telemetry as incremental events, whether mechanical or business telemetry, recorded temporarily or permanently. When I design for telemetry, mocks aren't needed and tests stay soluble. I value separating evented process state from the application data used for things like display to users. Intermingling the two limits productivity and continuity.

An observation about test-driven design that often goes unnamed: the setup of a test shows whether a design isn't compartmentalized enough to serve engineer productivity, and hints at further looming problems for operations people. Test-driven design is intended as a leading indicator in addition to a correctness check. Test setup difficulty surfaces design problems early, creating pressure to improve before coupling obscures the early symptoms.

In a hypothetical hierarchy of needs of design, I value principles most, then patterns, then frameworks, and then tools.

## Product Design

In product design, I engage through human factors psychology with as much vigor as I engage with commercial imperatives, and then navigate the tension between these factors and their stakeholders. Product design to me means giving users powers. Users first, then commercial, then operations, with full awareness that day-to-day product work involves balancing all three.

The ideal product interface dissolves on contact with a user, becoming largely invisible to the user — whether it's the user interface, product operations and support, an API, or the implementation code itself. Users know what to do next at a glance. The product is soluble — dissolving immediately into understanding.

When I trace lost productivity, it usually comes from a user's or engineer's lack of immediate understanding, either of how to proceed, or of how their next action may affect the outcome. The second case is subtler and often more damaging.

I concentrate more on usability and functionality, and defer deep dives into aesthetics until functionality has settled. I'm rigorous about a project's style guide, preferring an executable style guide to tribal knowledge.

## Continuity

Continuity is about a team's ability to keep making changes without interruption or setbacks. Design either builds toward that or erodes it.

The essential tension between speed and continuity isn't a trade-off but a genuine dialectic: speed without continuity accumulates liability; continuity without speed is a different kind of setback. The design qualities that I'm partial to — telemetry, compartmentalization, test control as diagnostic — are the structural moves that help to reconcile speed and continuity.

Design mistakes don't tend to do anything as obvious as crash software. Instead, they malfunction teams and projects. They start at a cellular level, compound along coupling lines, and are most correctable while still microscopic — which is also when they're least visible. Every increment of erosion is something an engineer leaves behind, and every increment of continuity is something an engineer creates. It's not always intentional. Working to make continuity's contributing factors visible makes design more intentional.

I see the same tension in production systems: throughput against quality. The balance sheet from earlier applies. Proven work as asset, unproven as liability.

## Production System Thinking

For over twenty years I've studied how high-performing production systems and product development systems pursue throughput and quality simultaneously, from primary texts and with ongoing direct relationships with teachers and practitioners in the field. I have considerable experience translating these practices and mindset to software product development, including organizational design, team structure, workflow, and culture.

## Testing Philosophy

In testing, I center on structural design: building transparency and telemetry into systems as essential design elements, not afterthoughts. Observable behavior is a design goal, not a debugging convenience.

I encourage engineers to see that interactive testing (or "manual" testing) is critical to a complete testing practice, and isn't always something to be eliminated by automation. Human inspection has its own value, even as AI takes on more of the work.

Fully-automated checking for fully-automated testing, partially-automated checking or no automated checking for interactive testing. In both cases, full automation for system state control (or as close to it as possible). The production systems notion of "autonomation" is evident here: automation built in support of user effort.

This philosophy connects directly to how I design systems: components should be transparent about their state and behavior by design, making both interactive and automated testing a natural consequence of good structure rather than an effort layered on top of it. I translate user flow maps into test infrastructure, connecting UX modeling to technical verification in a coherent process.

Test isolation is a design concern, not a framework affordance. The framework enforces design constraints, and the tests reflect them. Test setup difficulty has a mechanical explanation: coupling makes it hard to put the system in a controlled state, and that difficulty is the connection between testing practice and design quality. Test tooling benefits from a minimal, stable API without the kind of "magic" that obscures a test's operation. Stability over elaborateness supports continuity.

## Working with AI

In the past, I've been hesitant about AI's use in software engineering. It appears to be a common thread among people who come from an XP and test-driven design background, as I have. The skepticism was rooted in the precision and outcomes that hard-won techniques have produced. Bringing AI into a discipline built on small, controlled, provable steps looked like a risk to those outcomes.

As I've woven AI into my work both inside and outside of software, I've made the transition from resisting AI to becoming fascinated and excited to see how these things will be integrated into a cohesive mindset. It's not clear to me yet what it will look like, but I'm no longer skeptical that AI and the rigor I brought with me can be reconciled, or that a much more powerful set of capabilities will result. I can't imagine what they are, but I'm excited about what will be discovered along the way.

The AI writes under my direction. I also learn things in unfamiliar domains by inspecting the AI's products. I treat AI output the way I treat any other artifact: as evidence to be examined. I'm now learning to integrate the AI into the proofs and inspections themselves. The specifics aren't yet clear to me, but I'm excited about the possibilities.

My progression has been typical. I've retooled my homespun rsync backup scripts, built a standalone Git porcelain that mimics some of the features I appreciate in Emacs (git-stage), an SMTP archiving utility, and a queue app for managing speaker turns in public meetings (speaker-queue). I'm now working on the next generation of the Eventide Project, including skills for both working with Eventide and working on Eventide itself. Each step has been at greater scope and in production-grade territory, rather than purely exploratory or experimental.

Three key takeaways have emerged from my experience so far. First, the rigor of controlled, micro-incremental, provable work that I brought with me into AI work pays the same dividends. The balance sheet of proven and unproven work, test-driven design as productivity diagnostic, and the discipline of compartmentalization all carry forward. Second, I have learned to trust the AI more. The trust started low and grew through experience. Third, I am excited about AI, and I feel refreshed. AI is adding energy to my work, and relieves the tech fatigue that I believed was unavoidable. It's resetting my expectations for product development work.
## Teaching and Curriculum

Teaching, curriculum development, and communicating complex ideas has been central to my work since 2000. I've developed and delivered workshops on software design, distributed and message-based systems, developer testing, UI testing, and test-driven design. I was among the first to teach and advocate general purpose data access frameworks to working engineers, well before ORM frameworks became standard.

I've created numerous curricula for both engineers and end users, with a consistent focus on clarifying and simplifying esoteric subjects, striving to make difficult ideas accessible without sacrificing precision.

Throughout my career I've learned from teachers and practitioners in the vanguard of their fields — software architecture, distributed systems, lean product development, and beyond, before those ideas reached the mainstream.

## Speaking and Community

I founded the Eventide Community Summit, ALT .NET Conf, KaizenConf, MonoSpace, and Progressive .NET in Sweden. I served as track chair for the DevTeach and InnoTech conferences, and served as Speaker Committee chair for the International .NET Association. Meetups and user groups I founded or co-founded include the Distributed Systems Enthusiasts Meetup, Lean Software Austin, Austin Software Design Study Group, Microservices Meetup, AgileATX, Agile Austin, and the Austin .NET User Group. I have spoken at and participated in Øredev, Explore DDD, GoRuCo, Lone Star Ruby Conf, Much Ado About Agile, the Norwegian Developer Conference, Stockholm Developer Days, Wroclove Poland, VSLive, Polyglot Conf, PostgresConf SF, PostgresConf Austin, and numerous other events across the US, Canada, and Europe.

As tools and techniques for remoting have become viable over the last five years, I've shifted my outreach toward remote coaching. The cohort self-selects, which makes it the more productive channel. I present a topic at a conference about once a year.