How I lead, and how it has changed

These are the teams where designers reported to me.

• eMedia, Design Manager. Built and led a design team of fourteen, with full hiring, performance review, salary planning, and team structure authority. I had sole hiring authority on six hires.
• APPTUI, UI Design Team Lead. Managed a multidisciplinary design team through fast delivery cycles.
• Finnx, Head of Product Design, 2025 to 2026. Directed a second designer. I set the direction, assigned the work, and ran review and critique.

The model I ran at eMedia still shapes how I organize work: small groups explore at kickoff, one design owner carries execution, and structured peer review holds the quality bar.

At Ontario Health, most of my leadership runs through influence rather than a reporting line. It is its own skill, not a substitute for the other kind.

• I mentor senior and intermediate designers across product areas.
• I started a cross-program UX and CX leads forum without a mandate. Leads bring projects in flight and open questions, and I have used it to introduce AI-assisted prototyping.
• I hold design quality across six partner teams to one shared standard.

When a second designer joined Finnx midway through, I gave them ownership of a real problem rather than a list of screens: the audit trail, the part of the product that had to show an accountant exactly what the system had done during a reconciliation. Their strength was visual systems work, and their first pass, built quickly with Claude Design, was a polished dashboard with charts, filters, and status badges. It looked great, and it was the wrong answer.

Instead of redesigning it myself, I brought it to critique and asked one question: what does an auditor do first when they open this? We did not debate it. We put the prototype in front of two accountants, and they skipped the charts entirely and went looking for a single specific action so they could ask how it happened. That evidence did the work I would otherwise have done with opinion. The designer reworked it into a plain, searchable log with one row per action, each row opening into a conversation with Edith about that step alone.

I then had them walk the CTO through the rationale themselves, and in that conversation they landed on the key requirement: every row had to reflect an action the system actually logged, not a summary written after the fact. That redesign shipped in the working prototype and was part of what we showed funders. More importantly, the designer came out of it owning the engineering conversation on their own, using AI for speed without letting it make the decisions.

What I would do differently is bring the accountants and the CTO in at the first sketch, not after a polished pass. AI tools make a wrong answer look finished very quickly, so the evidence needs to arrive before the polish does.

At eMedia 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. Each side learned from the other, the whole group became stronger designers, and several moved into more senior roles. Nobody was managed out.

At OCAS I had already set up biweekly interviews with call centre staff, so when password complexity turned out to be driving calls, the evidence was waiting. I put the call volume in front of the decision makers and approval came back immediately. Total inbound calls fell 15% after the fix. The full story is in the OCAS International case study.

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

At Finnx we had to decide how the system would behave when it could not confidently categorize a transaction. That choice shaped what the product was, how we pitched it to funders in the US and Singapore, and whether accountants would trust it, and each group saw it differently. The business side wanted a high automation rate and a confidence score on every item, worried that a system saying “I’m not doing this one” would look broken in a demo next to LLM-based competitors that always produce an answer. The CTO and engineering did not want to fake a confidence number: the system either had support for an answer or it did not, so a percentage would have been invented precision. The accountants did not care about automation rates. They feared a misfiled entry nobody catches until an audit, and they did not want to approve every transaction either.

I showed each group they were describing the same thing from different sides. I put the accountants’ interview findings in front of the business team: the slowdown was never volume, it was the handful of ambiguous items in each batch. That changed the question from “how do we automate more” to “what happens at the ambiguous ones.” For engineering, I designed around what the system actually knew instead of asking it for a score: act and report in one line when confident, show the candidates and ask when two answers hold up, and hand off plainly when there is no supportable answer, all backed by an audit trail of the system’s real actions. I co-built the front end with the CTO, so every side could see it working against the real system rather than a mockup.

The escalation and the audit trail became the centre of the funder pitch, and the business team’s biggest worry became our strongest point. Investors were already afraid of AI that fabricates answers, abstention was what the room responded to, and the pitch brought in early funding. See an AI that refuses to guess.

I hold partner teams to the same bar as internal ones, and my job is to make that bar reachable. I give them early mockups, clear specifications, and structured reviews, so most work meets the standard before it reaches me. At Health811 I worked with partner teams to move their usability sessions to neutral one-on-one moderation, and the evidence coming out of them got better.

Every system has a point where it stops being able to help, and I treat that moment as a design surface. The clearest example is an AI that refuses to guess.

I lead designers as a multiplier, not as the best designer in the room. My job is to set a clear quality bar and then give people real ownership of problems, not just screens, so they are accountable for outcomes like task success, adoption, or fewer support calls rather than a pile of deliverables. I run teams on a simple model: small groups explore, one owner executes, and peers review.

I keep designers close to engineering and product from discovery through shipping, because handing off specs is where good work goes to die, and I make decisions on evidence from research, real usage, and working prototypes rather than opinion or seniority. Critique happens regularly, and the work gets challenged, never the person. I lean on design systems and shared principles so consistency does not depend on me reviewing everything.

With AI speeding up prototyping and production, I spend more of my time framing the right problems and protecting room for research and judgment, and I teach designers to use AI for speed while staying responsible for what ships. I develop people by building roles around their strengths, giving honest feedback often, and helping them learn to translate between users, the business, and engineering, because that is the skill that grows designers fastest. And I earn trust upward by tying the team’s work to outcomes leadership actually cares about, so design has a voice where decisions get made.