Every engagement starts in the same place: understanding your system.
Not your tools. Not your org chart. Your system: the conditions under which your R&D organization is trying to do its work. What's creating friction. What's creating clarity. Where the real constraints are, and what's actually available to move them.
That's the work. Everything else follows from it.
The House of Software Value Delivery
Software is valuable when it meets needs. That sounds obvious, but most delivery frameworks skip straight to execution without asking: whose needs, and what kind?
The House of Software Value Delivery organizes those needs into three types: User, Business, and Technical. These form the three pillars of the framework. Each pillar has specific Attributes that describe what it looks like when that need is being met. For a Business pillar, that might mean Timely or Innovative. For a Technical pillar, Maintainable or Secure. For User, Intuitive or Accessible. The specific Attributes vary by organization. The framework provides the structure for identifying and naming them, not a fixed list.
The pillars rest on a foundation: the health of the delivery ecosystem itself. That ecosystem has its own Attributes, things like Collaboration and Continuous Improvement, that can be measured and improved independently of the pillars above them.
Alongside the pillars are layers of Tools. Tools at the foundation level act on the ecosystem. Tools adjacent to the pillars act on the User, Business, and Technical needs. Tools above the pillars validate whether those needs are actually being met. Attributes and Tools are fundamentally different things, and confusing them is where most process improvement efforts go wrong.
You can't turn a dial to improve Maintainability. It isn't actionable on its own. What's actionable are the Tools that influence it: your code review practices, your architectural standards, your technical debt prioritization. The same is true for every Attribute in the framework.
The failure mode I see most often: organizations measure their Tools (e.g. automated testing code coverage, ticket throughput, velocity) and treat those numbers as a proxy for the Attributes they actually care about. They optimize the measurement instead of the outcome. The House corrects that. We identify which Attributes have the most room for improvement, select Tools most likely to move them, and keep measuring the Attributes to know whether it's working.
Every engagement I do starts here.
Services
For R&D organizations that need senior leadership without a full-time hire.
The title matters less than the work. Depending on your organization's structure and needs, this engagement might look like a fractional CTO, a fractional VP of R&D, a fractional Engineering leader, or a Chief of Staff to your technical leadership. What stays constant is the approach: I embed in your organization, learn your system, apply the House of Software Value Delivery to diagnose what's limiting you, and build the operating model to fix it.
This is duration-based work: we agree on scope and cadence upfront, and I become part of your leadership fabric for the duration.
This might be right for you if:
Your R&D organization is growing faster than your processes can keep up with
You have strong engineers but delivery is inconsistent or unpredictable
You're navigating significant organizational change and need experienced leadership to hold the thread
You need a senior leader now but aren't ready (or don't have the budget) to hire one full-time
You have a leadership gap and need someone who can assess, stabilize, and build while you find the right permanent hire
What to expect:
We start with a diagnostic phase to establish a clear picture of your delivery ecosystem. From there, we build the operating model and I work alongside your team to put it in place. The engagement is collaborative by design. I'm not here to be the answer, I'm here to build the conditions for your organization to find its own answers consistently.
FRACTIONAL LEADERSHIP
For focused engagements with a defined scope and a clear outcome.
Not every problem requires an embedded leader. Sometimes you need a sharp outside perspective, a structured diagnostic, or a partner to help you build and implement something specific. That's what consulting engagements are for.
These are project-based: we define the deliverable upfront, work through it together, and you leave with something you can use.
This might be right for you if:
You know something in your delivery ecosystem is broken but can't isolate what
You're planning a significant change like a restructure, a process overhaul, or a new operating model and want an experienced partner in the room
Your team is stuck in a recurring pattern and needs an outside perspective to name it and break it
You want a second opinion on a decision before you make it
You're building something new (a team, a practice, a planning cadence) and want to get it right the first time
How it works:
We begin with a scoping conversation to understand what you're trying to accomplish and what success looks like. From there, I'll propose an engagement structure with a defined outcome. For organizations that aren't sure where to start, a standalone diagnostic engagement is available. We use the House of Software Value Delivery to assess your current state and produce a prioritized set of recommendations. That diagnostic can be a standalone deliverable or the foundation for a larger engagement.
CONSULTING & ADVISORY
On software delivery, process improvement, and people-first leadership.
I speak from experience, not theory. Every talk I give is grounded in real organizational situations: patterns I've seen across R&D organizations, frameworks I've built and applied, and lessons that don't make it into the usual conference circuit because they're too specific to be generic and too true to be comfortable.
Topics include:
The House of Software Value Delivery: a diagnostic framework for R&D organizations
Slow is smooth, smooth is fast: why the shortcuts that feel like speed are making you slower
People first: what psychological safety actually looks like in a software organization
From chaos to maturity: how R&D organizations build the conditions for consistent delivery
Forecast, plan, commitment: why your team's timelines keep slipping and what to do about it
Available for conferences, leadership summits, company offsites, and internal events. Talks can be adapted for technical and non-technical audiences.
SPEAKING
Not sure which fits?
That's what the first conversation is for. Tell me what you're working on and we'll figure out together whether and how I can help.