Leadership Team Building Organizational Design
Building teams that can solve bigger problems.
I lead by creating clarity, giving people meaningful ownership, and building the systems that allow strong teams to make good decisions without depending on one person at the center.
Team Development
Operating Models
Design Operations
Cross-Functional Leadership
My Leadership Philosophy
A leader’s job is to increase the capability of the team.
I started as a hands-on designer, and I still believe leaders need enough proximity to the work to understand what their teams are solving. But leadership is not about remaining the best individual contributor in the room.
My role is to create the environment where other people can do their best work: clear priorities, meaningful ownership, useful constraints, honest feedback, access to the right information, and room to grow.
The strongest teams I have worked with were not built around one heroic designer or manager. They were built around complementary strengths, shared context, clear decision-making, and systems that allowed good judgment to spread through the organization.
What I expect from leadership
- Make priorities and tradeoffs visible
- Give people meaningful ownership
- Coach rather than control
- Match people to the right problems
- Resolve ambiguity across disciplines
- Build systems that outlast the leader
How I Lead
Clarity first. Ownership second. Scale follows.
My leadership model centers on four responsibilities: setting direction, developing people, creating alignment, and building operating systems that allow teams to move with confidence.
01 / Direction
Make the problem and priorities clear.
Teams move faster when they understand what problem they are solving, why it matters, what constraints are real, and how success will be measured. I focus on creating that shared context before prescribing solutions.
02 / Ownership
Push meaningful decisions into the team.
I do not want every important decision escalating to me. I define decision boundaries, give people ownership proportional to their experience, and stay available for coaching, tradeoffs, and escalation when the situation actually requires it.
03 / Development
Build around strengths and growth.
I look at team composition through both business needs and individual development. Some people excel at ambiguity, systems, research, facilitation, visual craft, or execution. Strong leadership uses those strengths intentionally while creating opportunities to build new ones.
04 / Systems
Make good decisions repeatable.
Processes, design systems, critique rituals, research operations, documentation, and governance should reduce unnecessary friction. The goal is not more process. It is fewer problems requiring heroic individual effort.
Building the Team
I do not build teams of interchangeable designers.
Team structure should reflect the problems the organization is trying to solve, the maturity of the product, and the strengths and growth opportunities of the people doing the work.
Team Design
The right person for discovery may not be the right person for stabilization.
I think about staffing in terms of complementary capability. Early product exploration may need researchers, facilitators, and designers comfortable with ambiguity. Mature platforms may need systems thinkers, accessibility expertise, and designers who can work deeply with Engineering. Leadership means matching those needs rather than treating staffing as simple capacity math.
Problem Fit
Match the team’s capabilities to the type, maturity, and risk of the product problem.
Complementary Strengths
Build teams with different strengths rather than cloning a single idealized designer profile.
Growth Opportunities
Use assignments intentionally to stretch people without setting them up to fail.
Developing People
Coaching should create independence, not dependency.
I want people to leave a project more capable than when they entered it. That requires more than annual reviews. Development has to happen in the work itself.
01
Frequent Coaching
Regular one-on-ones, critique, pairing, and project conversations create opportunities for feedback while decisions are still fresh.
Feedback becomes part of the work instead of a surprise delivered during performance review season.
02
Increasing Scope
As people grow, I expand ownership from individual deliverables to workflows, stakeholder relationships, strategy, facilitation, and eventually leadership of other people.
Growth is reflected in the complexity of the problems someone can own, not simply the polish of their artifacts.
03
Clear Expectations
Career frameworks and role expectations create a shared language for discussing performance, growth, strengths, and gaps.
People should understand what the next level requires before they are asked to demonstrate it.
04
Leadership Opportunities
I look for real opportunities for team members to run critiques, facilitate workshops, own stakeholder relationships, lead initiatives, or develop specialized expertise.
Leadership is a capability people can practice before it becomes a title.
Cross-Functional Leadership
Strong design teams cannot operate as a separate island.
One of my core responsibilities is creating a productive operating relationship between Product, Design, Engineering, Architecture, research, and business stakeholders.
I focus on moving important conversations earlier: what problem we are solving, what constraints matter, what risk we are accepting, how we will measure success, and who owns the decision. Better collaboration does not require everyone to agree. It requires teams to understand the tradeoffs they are making together.
What I try to create
- Shared product context before execution begins
- Clear ownership for decisions and tradeoffs
- Engineering involvement before solutions harden
- Research connected directly to product priorities
- Design standards that accelerate rather than constrain delivery
- Escalation paths for genuinely difficult decisions
Leadership in Practice
The evidence is in what the teams could do afterward.
Across my leadership work, the most meaningful outcomes have come from improving both the products teams delivered and the systems they used to deliver them.
Practice Built
Built a design and research function from the ground up.
System Adoption
Shared design foundations adopted across product teams.
Fewer Handoff Errors
Clearer operating practices improved Design and Engineering continuity.
Less Rework
Shared standards and earlier validation reduced implementation churn.
Selected Leadership Story
Building Design into a Strategic Product Capability
At LINQ, I built a design and research practice from zero to eight people while establishing research operations, design-system governance, career frameworks, and a stronger operating relationship across Product, Design, and Engineering.
That work became less about growing headcount and more about creating an organizational capability that could influence product strategy, reduce duplicated effort, and continue operating without depending on one individual leader.
Leadership demonstrated
- Organization design
- Hiring and team building
- Coaching and career development
- Research operations
- Design-system governance
- Executive and product influence
The Principle I Come Back To
Build the conditions for good people to do exceptional work.
My measure of leadership is not how many decisions flow through me. It is whether the people and systems around me become more capable, confident, and effective over time.