Design Leadership

As a manager and leader, I rely on learnings gathered from twenty-five years in the field.

How I Strive to Show Up

  • Building Culture Inclusive, Safe, Passionate. I strive to create an environment for my teams that is inclusive, multi-disciplinary, safe, and encourages passionate investment in the products we deliver.

  • CoachingCurious, Consistent, Invested. I want my teams to aspire to achieve as much as possible in their career. As a leader, I much coach them in a manner that leads them to build the skills they need to thrive.

  • CommunicationClear, Concise, Storytelling. I communicate with my teams – and help them communicate with their partners – in the most effective manner possible.

  • Hiring – Respectful, Discerning, Diverse. When hiring, I recognize that I am the face of the company for the candidate. I’m careful to set aside bias, look for opportunities for candidates to bring something new to the team, and always treat them with the utmost respect.

  • Treat people like you want to be treated.

    Make space for new points of view: The odds are you’ll be pleasantly surprised.

    • Ship often: If you don’t ship it, it doesn’t matter how beautiful or amazing it is.

    Strong opinions, held loosely: Be able to formulate a point of view and defend it – and then be able to change that point of view when needed.

    Make the distinction between priorities and sequencing: They are two different, but closely related attributes of a product team.

    Structure your team around how customers use a product (workloads), not how the product is built (architecture). This adds complexity on your side because you have to manage across PM teams, but it’s much better for ensuring good cross-cutting experiences for customers.

    Make decisions, move quickly: If you let momentum slow it becomes much harder to pick things back up again.

    Assume you are going to get it wrong: Focus on resilience.

  • • No New UI: The bar for adding UI should be high. Once it’s there, it’s hard to take away.

    Mediocrity is death – signal is critical: the worst thing you can make is something that’s not bad enough for people to speak up.

    Who’s the customer? What’s the problem? Unless you can answer these questions, you are not designing anything.

    The earlier the change comes in the process, the cheaper it is to fix. Changes to codebase require a lot of extra overhead.

    • Reduce the number of variations: One “bad” version is better then a few mediocre ones – it’s easier to improve when you’re making the change just once.

    Make it measurable AND visible: The graveyard of failed products is full of unprocessed telemetry.

  • Think about the system from the moment you start to design something.

    Reduce the cost to making decisions: Make it easy to change… But set the threshold for making a change high (think, “No new UI).

    Resist the urge to make things more complicated: Complexity will take care of itself without your help. Often the desire to add complexity comes from a need to be heard – to sound smart – or from a place of fear that if we don’t account for all the possibilities we will fail.

    Think full-cycle: If you can create it, you should be able to delete it. If you can name it, you should be able to rename it. Always consider the system-wide impact of the experience.