Illustration by Emily Murphy for this article.

When I joined Gem there was no design team.

Many of the engineers, product managers, and customer success team members I would be working with had some experience with product designers, but nearly just as many had little-to-no exposure to product design!

Meaning one of my first tasks as Head of Design at the company was to introduce the function of product design.

In addition to getting to know our nearly 100 person organization, becoming familiar with the history and context of our product and business, as well as planning what the next year would look like for the design team I’d build, I needed to help others understand what product design would mean for the company.

Part of introducing product design was tackled over the course of three weeks as I jumped into one-on-one video calls with nearly every person in the company. During these calls I’d introduce myself, get to know the other person, and have a casual conversation about the company and the role design would play in it.

I also created a go-to document for anyone in the company to refer back to in order to address how I imagined the design team would spend their time over the next year.

What follows is the content of that document (only slightly edited to omit proprietary information) which I hope helps address the question any startup might face: what exactly does the product design team do here?

1. What is product design?

Our role as designers is to drive success across the entire, end-to-end user experience.

User experience design—or software product design, as it is commonly known—is the practice of creating goal-driven, user-informed products or features. How? Through product thinking, visual design, and interaction design.

Think of user experience as the complete experience someone has when interacting with our product. Everything from the interactions we use in our sign-up flow, to the way we deliver and message email notifications, even the layout and controls available in our help center and account settings are part of the user experience. Our design team's responsibility is to ensure that that experience—any touchpoint across the product—is of a high quality. We define quality by measuring that customers can do what they need to do with our product in a clear, efficient, and often enjoyable way. A way that also represents our brand values and beliefs.

A common mistake is to think design is just how something looks. It's not! Product design isn’t just about the visuals or user interface (UI) of the product, it’s about how someone interacts with what we build, how it makes them feel, and how they come to understand our product as "uniquely us.”

Building out the UI is just one facet of the work we do in design, the other work we do encompasses: defining and designing the user journey, conceptualizing interaction flows across pages and features, helping define product strategy and vision, creating a clear language to use across our product, and more.

(For a great overview of how we think about product usability, check out this resource from the stellar Nielsen Norman Group.)

2. How does the design team spend their time?

Here's how our team defines and prioritizes what we do:

50% of our time is spent transforming the user experience in the product. This means:

• Improving experiences for customers by defining and ensuring high-quality design, including ownership of all front-end interaction points (eg. our company website).
• Delivering a consistent, seamless, cohesive experience across the entire product. Through brainstorms, whiteboarding, product documentation alongside product partners, interactive prototypes, testing with customers, and working with engineers to ship designs.
• Conducting and participating in user research, including sales calls and customer success sessions.

35% is spent driving design change across the company. How? We do this by:

• Driving design standardization across the company—including branding and marketing collateral—by creating a common design language and set of practices, regular design reviews, and training sessions for the company.
• Representing design throughout the company, including creating presentations for board review or for providing regular updates at company all-hands.
• Conducting cross-functional design training programs and insights workshops, and generally functioning as an open culture of design.

15% is spent building a world-class design team. We invest in ourselves and our team by:

• Building and maintaining a globally recognized design team through sourcing, hiring, training, and personal development investments.
• Representing Gem's brand at functions and in press including speaking at conferences, publishing online content, and participating in discussion panels and community-led conversations.
• Developing design team skills, supporting the team through regular conference visits, workshops, and courses.

3. What does design collaboration look like?

Because design touches the entire end-to-end user experience of our product we must work in collaboration with other functions early and often.

As such, we take pride on our ability to pull-in (or be pulled-into) projects early. As well as partnering closely with engineering, product, customer success, sales, marketing, and other teams, to understand customer needs, envision product ideas and features, conceptualize and solutions, and follow-up on next steps.

In addition to ongoing project-based conversations in Slack channels and scheduled meetings, we work in the following ways:

Design Review Weekly

A weekly 30-minute to 1-hour session where anyone and everyone is invited to review the latest design work (at any stage). The agenda for this meeting is shared in-advance, and we show the latest work as well as the process which informed decisions for it (customer insights, wireframes, journey maps, explorations, prototypes, etc.).

Monthly All Hands Update

Each month design will provide an update in the company all hands to share top-level initiatives or interesting projects/insights.

Design can work with you to...

• Define and document product strategy and direction
• Create wireframes or user journey maps for specific features
• Test concepts with users in order to evaluate an idea or change
• Sort through conventional wisdom and research-backed data to inform decisions
• Produce and walk-through pixel-perfect compositions for implementation
• Create interactive prototypes to demonstrate an idea quickly
• Ensure a concept is easy-to-understand and follows Gem design standards
• Review work and collaborate through brainstorming

4. How can I better work with my designers?

Include design early and often!

Even if you think a conversation is too technically focused or not defined well enough, the earlier you include design the earlier we can start thinking about the user experience and the problems the team might encounter along the way to ideation.

Leverage design for more than UI.

Designers are often exceptional at problem framing, scope definition, and feature ideation. We can help visualize muddy ideas and rapidly experiment with ideas. It’s good to work with design on the visuals of something, but the visuals of anything are only one small part of what your design team can do for you.

Elbow designers if you aren’t seeing our process enough.

Design is only ever as good as the diversity of perspectives that go into the process. If we’re not transparent it means we aren’t getting your valuable feedback and insights into the work we do. If you aren’t seeing enough of our process, please elbow the design team and ask to see it!

Learn a thing or two about how design works.

I encourage all designers to make time for sitting down with cross-functional peers in engineering, product, sales, marketing, etc. to better understand how they work. Likewise: I hope all non-design peers will take time to educate themselves on how design works too. The more we can learn about each other’s roles, responsibilities, and processes, the better we can work together.

‍

Illustration by Dionne Kitching for this article.

Slow down.

Great wisdom for almost anyone in almost any situation, but especially for those interviewing for their next job: slow down. Doing so will do more for your interview than racing through a jumble of words or slides or motions. This is true for both the person being interviewed and the person conducting it.

Before you answer a question, when speaking about your past work, as you move through the real or virtual space: slow down. Give yourself a little time to take a breath. To reflect, consider, or open space for ideas and opportunity.

Slowing down can often feel like a waste of time. Like if we’re not moving at 100mph toward something then our time—in limited quantity—will slip away from us, unused. What if we don’t cover everything we need to cover in the conversation? What if we fail to make a point? What if there’s more to be said or done?

If you don’t say everything that needs to be said in an allotted amount of time, it’s ok. The reality is not everything needs to be said.

Each conversation in an interview should be setup to help you prioritize what needs to be said as well. You should ask: "What signal specifically are you looking for from this conversation?” Or "Is there a specific detail you’d like me to speak on?”

You can also always ask for more time, or a follow-up conversation.

Or you can work on improving how you communicate so you can say more with less (practicing an interview at home or with a friend is a great way to improve).

Undoubtedly there are times to move quickly, time to leap, but an interview is not one. Because when you’re interviewing you’re working on building a, hopefully, long-lasting relationship, and you can’t build a strong relationship without giving serious consideration to what’s being said or what’s moving (and what’s not).

Slowing down can feel like you’re leaving the interviewer hanging, but it really comes across as being thoughtful about what comes next. Slowing down means you’re thinking, not reacting, and thinking is a major part of what many of us today are hired to do.

If you want to improve your work, your relationships, and especially your interviewing skills: learn to slow down. Give yourself a little time before you ask or answer a question, before you make a statement, or before you move on to another slide.

Illustration by David McMillan for this article.

There’s no doubt the future of design systems is tool-agnostic.

Most of us have seen the problem already: as design teams shift and grow they need access to a consistent design language and component library in order to ensure consistency and to move quickly without sacrificing quality. But as they move across tools elements and attributes from the system are lost in translation.

Additionally, teams outside the design org—those who have historically been forced to rely on complicated intranets or going through unnecessary design tool onboarding—have a need for access to much of the same elements as the design team, despite not using the same tools day-in and day-out.

What this means is that an over reliance on design tools themselves for managing design systems isn’t working.

Building a design system in Sketch or Figma is great, but what happens when you need to access the same components in Illustrator or InVision or Adobe XD? How can product managers working on a slide deck or document, who want to leverage the same color palette or art library as the product design team, do so without sending a dozen requests to the design team?

The same goes for engineers: how can they stay in-sync with the design system without having to reference Figma or Sketch files every hour on the hour? Likewise: how does the design team ensure that what they’re working with is the same as what the engineers are building with?

The future is one tool for design systems.

Imagine being a design team where you can switch design tools without having to migrate your design system or brand attributes.

Or picture this: you just joined a new team and want to use the design system but can’t remember the URL for the intranet where it’s hosted or which project file you need to find and sync in order to look at the latest color palette or popup dialog design.

In some ways this future is already here.

Facebook’s design team, for example, has a powerful system-level tool that automatically syncs design system to designer’s computers. And anyone in the company can leverage their tool to access things like brand guidelines, typography, and icon sets. A small team of specialists focused solely on the design system spend time building, documenting, and syncing everything from color palettes for business or consumer products to complex components in the company’s app, called Design Pack.

Tools like Specify promise to give that functionality to any design team, anywhere. Through a custom application built to not only access the design system, but manage it too.

Many in-house design teams at large companies are beginning to build this future too. These design teams have the resources and expertise to build out tools that ensure the design system can evolve and grow—and that it’s easily accessible for anyone in the company—as the company does.

Personally, I’ve been obsessed with abstracting design system data from any central design tool (such as Sketch or Figma) for a long time.

I started by exploring means of making accessing the design system easier than not for designers, through things like plugins.

These custom plugins ensured the design system was kept up-to-date automatically and that teams could access the elements or components quickly without having to worry what element to use or where to pull it from. But such systems were restricted to the design tool of choice for the team, Sketch or Figma.

Lately I’ve been exploring how a simplified tool could help teams—and not just design but entire product teams—stay up-to-date on the latest design system and enable them to pull from it without having to even open a design tool.

Such a project would mean teams could use design elements like color, typography, icons, and art in any app: Google Slides, Excel, Slack, GitHub, etc.

Additionally, design teams wouldn’t have to worry about migrating their system over to yet another tool every time a newer, shinier one comes along. The team could manage one system in one place and that’s that.

I started working on such a tool in October of 2019, calling it Superb.

I’ve ended up with something I plan to use with my design team at Gem, but I hope to open source the project to enable other teams to use it (and improve it!).

The idea is simple: all design system elements are hosted in a server somewhere (AWS, GitHub) as JSON files. This aligns with engineering efforts as well, who need to pull in the latest system components or elements from a shared repository.

Because modern product design utilizes vector formats, hosting even complex components in a JSON format is pretty straight-forward. Apps like Figma and Sketch allow you to copy+paste raw components, or you can export them as SVGs which can then be shared in a JSON file.

Superb checks for the latest system files each time it’s used, then downloads a copy to the person’s computer so if they go offline they always have the latest resources.

The app exists as a status bar app at the top of the screen. You can open the app by clicking on it’s icon or using a global hot key command. This helps with the user flow, you don’t have to open another app to pull the latest color codes into Figma or to drag-and-drop artwork into your Keynote deck. Just use the status bar app to copy and paste elements or drag complete components onto your project.

Superb is broken down into a few categories via tab-bar the top of the app: colors, icons, type, and UI (which houses artwork as well as complex components).

In the future other tabs could be added for things like: layout, motion, interactions, shapes, and more.

When you open the app the search input becomes active, and you can search across all categories instantly. Not only does search work across element or component names, but also meta data like: color codes (hex or rgb), meta data (categories, guidelines, usage recommendations), and even synonyms (so searching for "notification” in the icons tab will return icons resembling bells, badges, and popups).

All completely customizable by the team in their JSON file. Users of the tool can further customize the experience in the app’s settings, customizing what information is displayed and copied (such as component name copying for engineers or vector copying for designers), and more.

And because the app is native (built in Swift and SwiftUI), all usage in Superb can be tracked via whatever analytics a design team is currently using. Google Analytics, Firebase, or a custom tracker.

Such analytics are valuable for design teams to see who is using what components, and how often. Meaning design system teams can now provide real-world metrics on the work they do and how valuable it is.

It’s still early with tools like Superb, but the writing is on the wall: design systems deserve to have their own place abstracted from the tools we use to actually design. Doing so will ensure more people can use them, that the way they’re used is flexible, and keeping our systems up-to-date becomes easier than ever before.

Illustration by Mariah Barnaby-Norris for this article.

"If you want to be a better contributor to the human condition, you have to understand that the most powerful thing you can be is yourself.” — James Victore

At some point in your career as a designer you might find yourself asking some hard-to-answer questions. Questions along the lines of: "should I learn to code?” and "even if I wanted to learn to code, what language should I focus on between Python, Swift, Kotlin, Java, Javascript, TypeScript, Ruby, C, or something else?” You'll probably end up asking questions about industry and craft too, questions like: "Should I focus my work in blockchain or self-driving cars or virtual reality?” Or "Should I focus on visual design or interaction? Should I host my portfolio on Instagram or Behance or Dribbble or a custom hosted website? Should I start a YouTube channel to grow my reputation? Should I be using TikTok for growing my network? Should I be concerned with neumorphism… is that even a real thing?”

For all the questions we find ourselves asking over the span of our careers I have come to learn the only truly appropriate response to each is: it depends.

Experienced designers love to use "it depends” as a response to questions because the reality of the world we live in is there is no definitive answer to anything. There are only appropriate answers to questions as dependent on things like context, needs, constraints, and resources. To quote Albert Camus from his essay The Myth of Sisyphus: "There are truths but no truth.”

Because the answer to any of the career questions we face is inevitably "it depends” we are then led to ask ourselves what our personal, individual answer would, in-fact, depend on. And in my experience there is really only one dependency to keep in mind when it comes to the work you do and how you do it: who is it you want to be?

That's it. That's the top of the hierarchy of career questions in terms of what's going get you the most return on investment. Who do you want to be? Such a critical question often leaves those it's asked of paralyzed with indecision. Unless you already have a clear vision of who it is you want to be, how do you even begin to conceptualize who it is you could be? Faced with this existential mirror of defining who we want to be, we turn to the world outside ourselves in hopes of uncovering inspiration.

We convince ourselves that anything that might help us answer the most important question about ourselves is de-facto "good.” We look to others in places like Instagram, YouTube, Twitter, and Dribbble, for inspiration. Each corner of the Internet rife with small nudges of who we might possibly want to become in our career.

Yet what we see through these channels are not realistic versions of anyone or any career; they're each meticulously curated feeds of idealized realities, not reality itself. The work posted by designers to Dribbble is rarely, if ever, real work. Instagram is famously where people go to share altered images of their otherwise imperfect lives and careers. The thing about looking to the Internet for inspiration is that it's all just carefully curated, manipulated, and intelligently selected thoughts and images of a fake world nobody lives in.

So here we find ourselves in pursuit of the unrealistic, overly trendy, and ultimately foolish. Many who go down this route often end up being unhappy with themselves and their decisions. And, again, it's no wonder why: when we look to the Internet for inspiration for our careers what we're really doing is looking at a made-up reality nobody could ever live in. We inevitably end back right where we started: uncertain of who it is we want to be.

The reality is that in listening to these digital sirens we not only betray ourselves and who we really are, we deprive the world of something it greatly needs: our true selves. By trying to pursue interests that are not our own—but instead belong to the algorithms and celebrities of the digital realm—we deprive the world of our real, true selves. Our authentic, wacky and weird, sometimes broken, often afraid, selves.

This is a hard lesson to learn, but it's true. It's taken me a good decade to come to the realization that I'm valued not because I follow some trends or because I work in a specific industry. I'm valued in my work because I'm wholly, authentically, weirdly, me.

If you find yourself pursuing trends, you're going to be disappointed when they fall short of expectations or otherwise don't pan out. If you're pursuing the career path someone else has taken, you're going to be frustrated when you don't get the same opportunities they did.

If you want to define a life that makes you excited to wake up every morning, that challenges you and propels you to stand out from others, that gives you a long-lasting and fulfilling life of work, the way to do that is to focus not on externalities, but to focus inward on yourself. The solution to defining your career is to create it for yourself. Through experimentation, play, and yes: failure.

Do not worry what others will say or think or whether you'll get more likes on your Instagram story one way or the other. Discover who you are, who you really are, by experimenting, by making things (including mistakes, as long as their mistakes on your own terms and not somebody else's).

Start side projects, not because they'll turn into a billion dollar business but because you are curious about how to to do the work. Go to local events in industries you're curious about, not because they're trendy but because you have a passion for what goes on there. Design in the styles and with the foundations you grok best, because that's what's going to set you up for success down the road.

In discovering and embracing your true self you will find some people won't like that version of you. Some people will be afraid, will talk down to you, or even blatantly reject you. That's ok. The world is an extremely big place and thanks to the Internet we're more connected than ever before. If you be who you really are what you'll find is others like you will inevitably connect with you. Then all the haters simply won't matter any more.

Worry more about moving and less about where to place your feet. That's how you create value for the world and happiness for yourself.

Illustration by Raúl Gil for this article.

The answer is often: to an entirely different role.

This is an unfortunate reality playing out in product companies today, where after a few years those in IC—or "individual contributor”—roles find themselves seemingly stuck.

Stuck in their ability to garner additional responsibility and impact within the organizations they are part of. Stuck in their place on the career ladder, perceiving themselves unable to move higher without having to switch to a different ladder altogether.

I've spent the better part of the last year talking with various designers and design leaders about this "career ladder stickiness” and the situation is confusing at best. What is clear about the current situation is designers in the role of individual contributor feel as though the optimal (or in some cases: the only) way to grow in their career after a point is not to stay the course as an IC, but instead move into the role of formalized leadership. Typically as a design manager or director/head of design at a smaller company.

I've felt this pull myself.

Note: this is understandably not a problem unique to design. IC product managers, researchers, writers, analysts, and engineers find themselves in the same situation. For the purposes of this article I will be focusing solely on product designers.

Common belief at this point is that the only (or best) way to have more impact and readily available influence as a designer is to move into a formalized leadership role, typically a design manager or that of a director or head of design at a smaller company or startup.

This fallacy is highlighted in numerous places, such as this well written article by Josh Taylor, former Director of Design at Evernote:

I see a lot of designers who continue to expand their craft and simultaneously build their muscle for impact. And then a strange thing happens. At some point, many of us are forced to let go of one of the outer layers in order to keep scaling our impact on the world.

Josh explains that as designers progress in their career—as they hunger for more impact from the work they do—the way for them to continue growing is by moving to doing different types of design. Away from product craft and execution and more into team and organizational design.

This shouldn't be the case. I believe the last thing we want to teach designers is that the only way to scale their ability to make an impact on the world is by moving into team or organizational design.

The tangible work done as a designer—the screens and flows, the interaction patterns and project strategies, the ability to create vision and align a team behind it—has the ability to influence and create impact just as much as that of organizational design.

But the two are obviously not the same. Designing a product and designing a team are possibly equally important in terms of the impact they can potentially have, it's just they're focused on different legs of the same chair.

Today we lose many remarkable IC product designers to the management track because it doesn't feel like there's any other way to grow and do meaningful work at-scale. We continuously teach others that people managers have more influence and impact on the world than ICs, partially because the inherent power dynamic of someone who makes design decisions vs someone who makes decisions that directly impact the career of the other person.

Look to the example of Russ Maschmeyer, former designer turned design manager back to product designer at Facebook (and a former manager and mentor of mine), who in his 2017 Leading Design talk There and Back Again states:

I said yes to becoming a manager because I was afraid of losing my opportunity to lead. I bought into this corporate, cultural assumption that moving into management was the only path to leadership in the workplace.

One problem with this perspective is that being an IC product designer is a completely different job than being a design manager or director.

A product designer is ultimately responsible for outputs and quality, while people managers are directly responsible for people and processes in the organization. At least, in a perfect world that would be the case.

Rather than having to move into a management role to become a formally recognized leader, high-level IC designers should be utilized on larger and larger business and product problems.

What this looks like in practice will vary from team to team and business to business, but at it's core it comes down to giving very senior designers the responsibility to make business-level product design decisions, maybe even more than that. Along with the added responsibility: fair treatment alongside their people-managing counter-parts.

This equality matters, because there are many of us who immensely enjoy the tangible output of our work more than we like the idea of helping define career paths, providing opportunities and cover for teammates, or negotiating career pathways for those we work with. The craft of the work itself—the shapes and colors, interactions and flows, ability to clearly communicate a vision and rally a team behind it—is as important as building a team itself.

Part of the challenge I've observed is that these ever-expanding responsibilities for IC designers often overlap with the perceived work of the designer's manager, or the manager's manager.

Either as a result of poor leadership or immature organizational structure, the manager sees their role as being not only to assign tasks and help manager careers, but also to define the quality of the work and single-handedly own product vision and direction. This mental model is a direct conflation of the creative agency legacy, where Creative Directors are accountable for not only the individuals on their team, but the output of that team.

A design manager's energy is better spent overseeing the decisions behind the work setup and managing the teams themselves, unblocking members and bridging gaps across teams, not managing or owning the design output and strategy.

One way I've seen companies try to resolve this issue is by introducing clear levels and roles for designers, assigning new skills and responsibilities to equal levels. This approach sounds great on paper but regularly doesn't translate to the real world. The majority of companies I've spoken to who have introduced these role ranges or levels tend to not even have designers anywhere near the top of the list.

This issue of senior ICs feeling like they have to move away from actual production work isn't going to get resolved simply by adding IC levels with fancy titles for very senior designers.

Labels and titles certainly help the situation—particularly as it relates to internal teams recognizing an individual's responsibilities and experience—but unless those levels actually represent expanded and internally (as well as externally) recognized roles and responsibilities, a nice title and set of skills on a spreadsheet are not going to be enough to pave a pathway for senior ICs.

What might this look like if we lived in a perfect world? How might IC designers continue to feel confident that staying in the role of producing work is a life-long career path?

1. Explicitly clarify manager vs. senior IC responsibilities

Truly senior ICs may need to be in design-focused planning and strategy meetings, sometimes at the highest level. They may need to have more control of the direction of the work than managers may feel comfortable giving them. In either case: company's should define IC career tracks and roles and also explicitly clarify what differentiates those senior IC levels from that of their managerial counterparts. Openly and honestly.

We need professional arcs that decouple design decision making from people management.

— Maxim Leyzerovich (@round) June 4, 2019 When push comes to shove: outline who gets the final say, and why. Overlapping responsibilities between IC and managers is the most prominent issue I've observed, but it's an easy one to resolve by looking at where the line is drawn between people and product on the team.

One new pattern I'm beginning to see is a hybrid role where the individual is responsible for their regular IC work, but also afforded the option to formally support one or two individuals on the team. In some circles this is known as the player-coach model.

2. As an industry, we need to treat senior ICs as equals alongside people managers

Being a "Head of Design” is certainly a different job than being a "Principle Product Designer” and each has unique roles and responsibilities within a team, but both ICs and managers should be treated equally where it makes sense to do so.

In the product design industry we've gone ahead and created this mismatch between how we treat people managers and senior ICs. As Russ—mentioned above—highlights in his Leading Design talk, we often view any step away from management back into designing as a step literally downward:

I committed what some might consider a demotion, or career suicide, by going to my manager and asking her if I can just be a designer again.

This is a real problem nobody should have to confront in their career: debating doing what they love and are good at vs. what will get them more clout.

How can we open doors for ICs who are effective at leading and scaling their work? How can we welcome more senior ICs to the conversation around what it means to lead a team or project, to navigate muddy business decisions, to inspire and uplift those around them.

Today there are numerous design events with the message of "leadership” behind them. Conferences like Clearleft's Leading Design and DesignX's Design Leadership. Yet time and time again the only people asked to speak on the stages of these event are formal people managers: directors, managers, heads of design, and VPs.

If we're really going to talk about design leadership let's invite not just people leaders but design leaders. Not just Managers and Heads of Design, but senior designers too. If we're not willing to do that, at least change all of these leadership events to be more honest in how they describe themselves. They're not about "design leadership” they're about "leading designers.” There's a real distinction we—as a collective—have failed to call attention to.

3. Standardizing IC leadership leveling

Titles aren't everything, but they do create a perception around us as individuals and what we're responsible for and what we can bring to the table.

This is a difficult point for many leaders to come to terms with, but after countless conversations with IC peers, it's a reality we must face.

If someone with the title of "Designer” or even "Senior Designer” speaks in a room, they will receive a very different reception to someone with the title of "Head of Design” or "Design Manager.” Simply because the perception is that the designer reports to the other individual, therefore the loftier title has more naturally authority. This is a misconception, a false belief, but it persists in countless organizations. It's difficult to break biases around what someone's title means.

Titles like "People Manager” or "Head of Design” are equally difficult to parse as titles for individual contributors, but formalized leadership titles come with a bit of pre-established understanding even outside a company. We can assume someone with the title "Head of Design” had to lead a team—either of one or two dozen—but it's assumed they have some experience shaping a team of individuals.

A person with the title of "Lead Designer” or "Senior Designer” may or may not have experience leading a team of cross-functional peers toward a solution. They may or may not have experience formalizing a product vision and working closely with key stakeholders to execute on that vision. It really depends on the company they come from and even the location of that company in the world.

If we as an industry could better standardize IC designer titles we might make it easier to better acknowledge what skills a single designer possesses (without having to dig through the case studies in their portfolio), both internally and externally.

There are already a number of companies who have publicly opened up leveling for designers and managers at their company. It's worthwhile for companies, managers, and ICs to read through these resources and either 1. Contribute feedback to the company who shared it, on how they might change or improve their leveling, or 2. Utilize these resources to structure their own leveling.

Here are a few examples I'm aware (last updated December 23, 2019):

• Intercom product and content levels
• BuzzFeed product design roles
• Basecamp titles for designers
• Buffer level and step placement guide
• GitLab product designer roles
• Clearleft development framework
• Gov.uk graphic designer roles
• ZenDesk product design career paths

4. Celebrate senior individual contributors who lead as examples

This last point is tricky. Looking out at the industry it's hard to find very senior ICs who are a strong voice or who take time to share their work, processes, and ideas.

A common excuse I've heard for the lack of senior ICs is "they're senior designers so they're busy doing their work, too busy to write a blog post for the public.”

This is a false belief, as a core tenant of being someone in a senior position is the ability to lead others and contribute to the industry as a whole. Just look at the list of levels I included in the previous point, at the senior-most level for each there's something about contributing back to the community or industry.

So where are the senior ICs?

I believe the reality is these senior ICs are a minuscule minority (because the majority have transitioned to people management) and aren't celebrated as much as those in managerial roles. Again looking back at point #2 above: as an industry we just don't treat senior ICs as equal as design managers or VPs of design, though we should. So their voices are quiet and even when they do show-up, they're not as celebrated.

What can we do to celebrate more when these designers speak up? When they take the time to show up and share their process or struggles, when they ask to have a ticket on the speaking circuit or when they tweet something other leaders—formal or otherwise—might learn from?

Here's the thing...

I don't have all the answers here. I'm not claiming to have the answers. In-fact: after countless discussions and writing this article, I'm left with more questions than solutions.

But I hope this is enough to keep the dialog going. As design leaders: how can we create a better ecosystem for senior ICs? As ICs: how might we engage our organizations and peers in a way that helps them understand this difficulty?

I believe—as I'm sure you reading this—that leadership and the ability to have impact in a company has little-to-nothing to do with title or explicit role. Anyone can lead, by building trust, exemplifying values, and committing oneself to the work. The ability to have impact is more of our ability as individuals to do what we love doing in a way that provokes others to do equally as meaningful and scalable work.

To once again quote Russ Maschmeyer's talk from Leading Design:

Leadership is not a title. It's not an authority granted to you from on high. It's an energy and influence born of loving what you do minute to minute, and allowing that energy to overflow into the hearts and minds of the teammates around you.

And yet, so many IC designers feel like the work they put into building organic leadership is stifled: by title, by industry perception, by mislead managers.

It's time we as an industry start seeing the career track of individual contributors as that on par with people managers. It's not lesser to choose to be an IC. It's not really an upward leap to move from IC work into people management. These things are different, both are equally needed on any sizable team. Both matter.

Where should IC designers go once they hit their peak? Hopefully somewhere even higher on the same trajectory they've taken their entire careers. Upward, not adjacent.

‍