My Approach

Over the years, I've found that many of the same principles apply whether I'm designing software, making architectural decisions, leading people, or building a business.

Understand the problem. I like to understand what we're trying to accomplish, why it matters, and what success looks like before deciding on a solution. Sometimes the most valuable contribution is questioning the original request.

Keep it simple. I favor straightforward architecture, minimal code, and only the process needed to achieve the objective reliably. Complexity has a cost, and I believe it should earn its place.

Focus on a few things and do them well. I'd rather make meaningful progress on a handful of priorities than have everything moving and nothing finishing.

Help people succeed. I believe my role is to help people actually succeed, not simply give them an opportunity. I want to understand their strengths, motivations, and challenges, and provide clear expectations, support, and accountability without fear. Sometimes success means finding a different role or organization.

Give people room to make decisions. I prefer to establish direction, agree on boundaries, and provide the safeguards needed for people to take ownership. Effective delegation requires trust, clear expectations, and the willingness to let others approach problems differently than I would.

Build a system that works. I value clear priorities, responsibilities, accountability, and regular opportunities to evaluate progress. I've spent years helping implement and apply the Entrepreneurial Operating System (EOS) in day-to-day leadership. I've found it valuable, but no single framework fits every organization. What matters is finding an approach that fits the organization.

Be direct, and seek to understand. I regularly ask people three questions: What's working? What's not working? What's pissing you off? That last question is deliberate. I want to understand what matters enough that someone might disengage or leave, including when the problem involves me.

Make decisions and take responsibility. I value different perspectives and thoughtful analysis, but I don't believe every decision requires consensus. When a decision is mine to make, I'll consider the information available, make the call, and take responsibility for the outcome.

Change when warranted. When something goes wrong, I want to understand what happened and why. I believe in learning from mistakes and improving what isn't working, but not every problem calls for a new rule, process, or architectural change.