Hands-on when it matters. Strategic where it counts.
Some teams don’t need a fully hands-off design leader or a pure IC. They need someone who can set direction, build systems, coach designers, and still ship real work—especially during moments of growth, ambiguity, or transition.
That’s the lane I’ve spent most of my career in.
At Vimeo, Teachers Pay Teachers, and Quit With Jones, I operated as a player-coach: leading teams and strategy while staying close to the product. The goal was never to “do more design,” but to contribute at the right altitude. Where hands-on work removed ambiguity, accelerated decisions, and strengthened the team.
At Quit With Jones, that meant redesigning the mobile app end-to-end, establishing a scalable design system, and standing up a more structured UXR practice. The system wasn’t theoretical. It grew directly out of real product needs, engineering constraints, and active research. Leadership decisions were grounded in execution, and execution benefited from clear direction.
→ Case study: Jones App 2.0, Design System & UXR Foundations (coming soon)
At Teachers Pay Teachers, I was hiring and managing a growing design team while remaining hands-on in high-impact areas: the Easel Quizzes MVP, marketplace, and checkout redesigns, and vision work such as the My Library redesign, which influenced platform-wide thinking. Alongside that, I helped define design principles and the rollout strategy for a new design system, partnering with Design Ops and the front-end team while staying close enough to the product to make smart sequencing decisions.
→ Case studies: Easel Quizzes MVP · Marketplace & Checkout Redesigns · My Library Vision
Across both roles, the pattern was consistent. Leadership created clarity. Hands-on work reinforced trust. And systems scaled because they were rooted in real use, not abstractions.
If you’re looking for a design leader who can lead without floating above the work and ship without crowding the team, this is how I operate.
The Player-Coach, In Practice
What it looks like when leadership and IC work reinforce each other
The player-coach model only works if it’s real.
Not “I still open Figma sometimes.” Not “I review work closely.”
But leadership that actively contributes at the right altitude, at the right moments. Without undermining the team, and without disappearing from the work entirely.
I’ve spent most of my career in exactly that lane: teams that needed direction, systems, and culture while also shipping critical product work. Two recent chapters show what that balance looks like in practice.
Quit With Jones: Building the plane while flying it
Design system, full app redesign, and UXR at the same time
Jones was at a classic inflection point: a growing product, a strong mission, and increasing complexity, but without the design infrastructure to support what was coming next.
The work required leadership and deep execution.
Leadership vision
The mandate wasn’t just “make the app better.” It was to:
- Redesign the mobile app end-to-end (Jones App 2.0)
- Establish a scalable design system
- Introduce a more structured UXR practice
- Create alignment between product, engineering, and brand
This meant setting direction, sequencing work, and making tradeoffs, often before all the answers were obvious. I worked directly with the PM to translate research insights into roadmap priorities, drafting PRD documents, user stories, and “how might we” frames that gave the team shared language for the problems we were solving.
Hands-on IC contribution
At the same time, I was deeply embedded in the work:
- Designing core product flows during the complete app rewrite
- Building and documenting the design system in Figma (tokens, components, usage patterns)
- Partnering directly with engineering to ensure production-ready designs
- Working with research to stand up diary studies and feedback loops that hadn’t previously existed
But the IC work went deeper than handing off Figma files. I was in daily standups, working from Jira boards, collaborating with engineers on design system implementation details, and understanding a backend services rewrite so we could make smart decisions about how the front end should support it. This level of partnership meant designs shipped faster and with fewer surprises.
This wasn’t parallel work. It was reinforcing. The system emerged from real product needs. The product redesign benefited from shared patterns instead of one-off decisions.
Why this worked
Because leadership wasn’t abstract, decisions about systems, scope, and sequencing were grounded in hands-on reality. And because I was doing the work, gaps surfaced early, before they became expensive.
→ Case study: Rebuilding Jones App 2.0 while establishing a scalable design system and UXR practice (coming soon)
Teachers Pay Teachers: Scaling a team without losing momentum
Hiring, managing, and still shipping critical product work
TPT presented a different but equally instructive player-coach challenge.
The design team was growing quickly, the product ecosystem was expanding, and the platform served a deeply nuanced user base (teachers, authors, administrators). Leadership demands were real, but so was the need to keep shipping.
Leadership responsibilities
During this period, I was:
- Hiring and managing a growing design team
- Establishing career paths, critiques, and team rituals
- Partnering closely with product and engineering leadership
- Helping define design principles and the rollout strategy for a new design system (with a dedicated Design Ops partner and the front-end team handling implementation)
Much of the leadership work happened upstream: collaborating with PMs to shape roadmaps, extracting learnings from research and translating them into PRD documents, user stories, and problem frames that aligned the broader team.
Meaningful IC contributions
Alongside that leadership work, I stayed hands-on in targeted, high-impact areas:
Easel Quizzes MVP – Served as an IC on the initial MVP, shaping the product at a moment of high ambiguity and urgency. I worked hand in hand with the PM to define the scope and project direction, writing user stories and shaping the MVP to keep it grounded in what we knew teachers needed. This meant daily standups with engineering, working directly in Jira, and staying close to implementation constraints as we moved fast.
Marketplace redesign – Contributed directly to redesigning key discovery and evaluation flows for teachers. Because I had been in the room at a leadership level, I understood the key KPIs the marketplace needed to move. This allowed me to design tests specifically to improve those metrics, connecting strategic goals directly to execution.
Checkout flow redesign – Worked hands-on to reduce friction and improve conversion at one of the most business-critical moments in the experience.
The IC work here wasn’t just about delivering polished screens. It was about being in the room when technical decisions were made, understanding backend constraints, and making design tradeoffs that engineering could actually build.
→ Case studies: Easel Quizzes MVP · Marketplace Redesign · Checkout Flow Optimization (coming soon)
Vision work that influenced the broader team
Some of the most valuable player-coach contributions don’t just ship. They set direction.
At TPT, that took the form of a My Library vision redesign: forward-looking concept work that helped the team rethink organization, scale, and teacher mental models across the platform. The work created a shared reference point for the rest of the team to build on.
→ Vision case study: Reimagining “My Library” and influencing platform-wide design direction
Systems thinking without slowing delivery
While others focused on implementation, my role in the design system work was about strategy and adoption:
- Prioritizing which surfaces to standardize first
- Sequencing rollout to minimize disruption
- Aligning system decisions with active roadmap work
Staying hands-on elsewhere in the product made those decisions sharper and easier to defend.
→ Strategy case study: Design system rollout at scale—leadership, sequencing, and adoption
Improving the top of the funnel
Beyond core product work, I partnered across design and marketing to improve user signup and onboarding, balancing education, data capture, and conversion while preserving the teacher experience.
→ Case study: Improving teacher signup and top-of-funnel conversion at TPT (coming soon)
What these examples have in common
Across both companies, the pattern is consistent:
- Leadership sets direction and creates space
- IC work is deliberate, not default
- Systems grow out of real product needs
- Teams scale without losing momentum
- Design credibility is earned through participation, not proximity
This is usually what hiring teams mean when they say they want a “player-coach,” even if they don’t always have the language for it.
Why this matters for the roles I’m pursuing now
Many of the roles I’m seeing (and actively pursuing) share the same tension: high expectations, small or evolving teams, big product bets, and a need for leadership that doesn’t slow things down.
They don’t need someone who will eventually stop designing. They need someone who knows when to create, when to lead, and when to get out of the way.
That balance isn’t theoretical for me. It’s how I’ve operated, recently and repeatedly.
Looking ahead
This page is the connective tissue. Each example above will stand as its own deep-dive case study, but taken together, they show how leadership and hands-on work can reinforce each other rather than compete.
More player-coach work (case studies coming soon): Easel Quizzes MVP · Jones App 2.0 · Design Systems at Scale · Marketplace & Checkout Redesigns · My Library Vision
Building a Team?
If you’re looking for a design leader who can set vision, build systems, coach teams, and still ship meaningful work, I’d love to talk.
Justin Dickinson 
You must be logged in to post a comment.