How I lead

The operating model I have refined since 2008

Small groups explore. One owner executes. Peers review. People develop faster when their roles build on their strengths. Decisions get made on evidence.

  1. The operating model

    Since 2008, small groups explore at project kickoff, one design owner carries execution, and structured peer review is the quality gate.

    At eMedia, 2008 to 2011, I grew the team by interviewing for six positions with sole hiring decision authority.

    It started with a fourteen person team at eMedia, and it is still how I run work today.

  2. Develop by strength

    I inherited designers who were exceptional conceptual thinkers but struggled with visual execution. I positioned them around their conceptual strengths and paired them with designers who had exceptional visual craft. Both became stronger designers, and I supported both into more senior roles.

    Develop people, do not manage them out.

  3. Evidence over persuasion

    At OCAS, applicants were failing to get into their own accounts because the platform enforced bank grade password complexity on a college application. They forgot, they called, they reset, they repeated. I traced roughly 15% of all support call volume to that one policy, put the number in front of the decision makers, and approval came back immediately. I did not have to build a case, because the number was the case. The reason I had the number at all is that I had already set up biweekly interviews with call centre staff, so the evidence was waiting before I needed it.

    I showed them the call volume and the decision made itself.

  4. The translator

    I am fluent across the C suite, product, engineering, QA, research, and policy.

    I help teams reach decisions everyone understands, supports, and can execute.

  5. Partners and vendors

    I apply the same quality standards across internal teams and partner organizations: early mockups, clear specifications, structured reviews, and unbiased research practices.

    When a persistent practice problem requires executive backing, I escalate the underlying structure rather than repeatedly treating individual symptoms.

  6. Design for the limits

    Every system has a point where it stops being able to help. That moment is a design surface, not an exception to handle later. The clearest version I have built: a system designed to refuse, where the entire interface problem was making the refusal legible.

    I would rather ship a system that says it does not know than one that performs certainty. Designing the failure path is not defensive work. It is where trust is built or lost.