Thriving as an Individual Contributor

Designers become managers of designers for a thousand perfectly valid reasons. Many of you have—or will—make that shift. Maybe I will, too.

Until that day, our challenge is to thrive as individual contributors: to keep the design jobs we want to keep without losing our souls, brains, or bodies in the process.

Design managers certainly do not have an easy job, but they do arguably have more source material to draw from to grow their career.

The IC path in design is more opaque, especially in tech. My hope is to spark more conversation in our industry about intentional paths to career growth.

I’ve heard from a diverse range of colleagues over the years that I can be helpful here. As best I can, I’ll contextualize my experiences and suggestions to make them relevant to everyone—while openly acknowledging the privilege inherent in
my experiences.

I’m open to feedback on my blind spots here, but I’m hopeful that what we discuss from here will help you thrive in your career, no matter who you are.

Let’s start here. To thrive as ICs, you’ll need to intentionally cultivate and balance both design skill and the trust of others.

Skill is easier to measure, especially by non-designers. But trust is just as critical.

Self-centered designers overlook this aspect, because they miss the deeper truth that effective design requires cooperation with others—even if you’re one person designing an app for one person to use.

You can design the ideal visual interface, but it’s only actually ideal if you can get another person to behave in a specific way in relation to it.

So let’s think about balancing these ideas over time, and how they lead to thriving long term.

We’ll use a helpful anecdote from author Simon Sinek—he once asked an elite military force how they decide who’s ready to perform in critical, high-pressure situations.

They drew this graph with the axes we’re talking about: skill and trust.

Naturally, they don’t want these folks …

… and they do want these. No surprises so far.

But then they added …

… that this person—someone with high skill, but low trust—is “toxic” to the team’s success. They may be incredible at what they do, but they can’t be trusted. They don’t want these people on the team.

They’d much rather have people with lower skill but higher trust. I would argue that that’s true of many of our potential employers, clients, and stakeholders—and even true of us and who we want on our teams.

In this anecdote, Simon reminds us that this “toxic” group is easily identifiable in contexts outside the military. Most people can point to the assholes on their team. Someone may have just come to mind for you in this moment.

Obviously, in terms of this chart, we’re all going to want to go to the top right as soon as possible. We want to be incredible designers with reliable success, and we’d like the full trust of everyone around us to implement our ideas.

But how we get from the bottom left to the top right matters as individual contributors.

No one’s path will be linear. But over the years of your career, you can calibrate where you are and try to point yourself in the right direction.

Along the way, asking for feedback—sincerely—and practicing self-reflection will ensure you avoid the undesirable corners of this chart.

Some of you will think trust doesn’t matter and you can be skilled enough to compensate for it, but you will be wrong, and you’ll pay for it long-term.

We’ll break this down into 3 specific career phases that are applicable across your overall career, but also in your current role.

For instance, even a very senior designer might apply ideas from the 0-to-1 phase in a new role at an early startup.

As we go along, try to calibrate where you are in these phases of your career and role. Think about where you want to go over time.

“0 to 1” is a helpful phrase that emerged in recent years. Whether you’re early in your career or starting a new role, starting with “0” is always how it feels, and your first step is always getting to “1”.

To navigate these moments, I think it’s helpful to return to some foundational elements of effective design work: what are we actually doing when we design an experience? Why are we doing it? And how do we try to measure success?

Whatever it is, we are doing it together with colleagues, customers, and users. No design is successful unless it producing a measurable outcome—even if that’s just designing a banner ad that gets clicked.

To start building consistent success, you have to get good at identifying the people involved—internally and externally—and consistently influence their behavior by incentivizing them.

For me, this idea clicked into place early in my career after encountering a book called Badass by Kathy Sierra, who was otherwise known for her wildly popular books on Java programming.

It reads more like a graphic novel than a book, and manages to unwind the entire concept of product design back into a simple idea: successful design work produces tools that other people use to be good at something bigger.

That’s not a vague abstraction—it’s a path to follow in design work.
Our goal is to design experiences in such a way that our customers become better at the larger, more compelling thing they care about, over time.
Accessibility, usability, “designing for emotion”—so many helpful ideas are contained in this approach.

It’s easy to think that career success means creating awesome products. Sometimes, that’s good enough to move your career along for a short time.

But in the long run, you’ll need to see success differently.

You’re creating awesome users of your product, who leverage it as a tool in their pursuit of a goal that has nothing do to with you.

Being an effective designer will require that you immerse yourself in that larger, more compelling context that has nothing to do with you, so that you can design experiences that get people where they want to go.

Making badasses for this compelling context is a macro-level goal of every stakeholder (even if they don’t describe it that way).

In this early phase, it’s tempting to go into that top left corner because you can impress a lot of people with polished design deliverables or working long hours, and you haven’t built up enough trust for anyone to expect measurable
outcomes from you yet.

So, they measure your output instead, and it might tempt you to optimize for it as the expense of building trust. Don’t fall for it.

The feedback that can keep us on the right track here is user testing: something external that validates your design work as achieving its intended goal.

With this feedback keeping our ego in check, we’re able to intentionally build trust through mutual success with increasingly diverse audiences: different combinations of colleagues and stakeholders and users and customers.

If you do not understand the power of intentional diversification—and you write this off as some sort of moral or political argument—you will not be a good designer in the long run. You will not build the knowledge or intuition you need to
produce outcomes at scale.

Intentional diversification is a skill that’s necessary for reliable user testing—a handful of similar people can teach you some things, but not nearly enough.

The broader your coalition, the more confidence you can have about outcomes at scale.

At the same time, we’re growing a complementary skill of iteration.

You will not get it “right” on the first try, or even the the millionth try—there is no perfect design. Instead, testing helps you identify weaknesses in your own design work, prioritize them, and then iterate them away without introducing new
issues.

If you wrap your ego up in your designs, you won’t want to test or iterate, because it’ll feel bad to constantly admit you’re wrong. And you’ll always feel the pressure of having to get everything right on the first try.

If you want to be effective, you’ll need to reject that idea of a perfect, spontaneously created design. You’ll need to show your colleagues that the design process is a way to refine the value of an experience, to the benefit of the business
and everyone else.

When you combine this mutual success with valuable iterations, you can inspire a whole team to engage in the process, and things can really take off.

One of the coolest projects I ever worked on was something called Engagement Studio—a visual automation builder for B2B marketers.

This is a creative rendering of the UI and shows where we ended up, but our team did not start here. Our co-founder had kicked off this effort and his guidance at the time was to make it “like Vizio”.

That was reasonable enough guidance, but that reference brought to mind a whole lot of examples we didn’t want to build.

Freeform canvases for drawing diagrams have a lot of crossover with workflow and automation mapping, but their relative complexity could be orders of magnitude apart.

Plus, a diagram is just a document, but an automation represents a whole lot of real actions taking place.

We asked if we could have 2 weeks to do some research before starting design. We had a small team of unreasonably smart people including research experts, which meant we could still get a lot done.

We did a handful of interviews with diverse customers in their offices. Instead of asking them questions about marketing software, we asked them about how they were already diagramming and planning automations.

These homegrown visual languages had enough in common to help us test and iterate towards a successful visual language of our own.

As we gained confidence in the UI, we were able to address higher level UX concerns. I mentioned that an automation represents a whole lot of real actions.

A decade ago, this bit of Mailchimp UI was somewhat famous, as a killer example of sweating the details in UX and meeting users where they are in that particular moment, emotionally.

And this was about sending a single email, once, to one list of people.

We were building a tool that would let you take that same action, dynamically, in billions of different combinations. And you still, at some point, had to a press a button to make it all go.

Our team eventually developed, tested, and iterated on a testing capability that let a user verify their automations by taking the journey themselves.

We added subtle animations and canvas zooming techniques to make the testing process itself engaging.

We knew we were successful not only because users were successfully testing their own work, but because they apparently … enjoyed it? They were calling this colored path the “yellow brick road” and “orange goo”.

It was giving them the confidence they needed to actually use the tool we were giving them. It was making them better at their jobs by making them better at using this tool. And the experience was polished enough that they were willing to
adopt it quickly.

Your skills will grow as you’re willing to validate your own work. Your trust will build as you make your teams, users, and customers successful along with you, through your design contributions and leadership.

As you enter this phase, your ability to thrive as an IC is wrapped up in your ability to help other people thrive. Your effectiveness at giving and receiving feedback will directly affect the quality of your work, and your ability to get results in
larger teams and at larger companies.

If you can’t receive critique in humility or deliver critique thoughtfully—that’s literally a skill issue.

You’ll need to build that skill yourself, and you’ll need to adapt it to the collaboration tactics of that moment.

For example, I still remember exactly where I was when I first opened a design file that looked like this.

Between real-time auto-saved changes, multiplayer capabilities, and visual commenting—this was already quite the shift to established process in 2016, when it felt like we were finally settling down with Sketch and InVision after finally get
out of Illustrator after finally getting out of Photoshop.

But then something happened in 2020 and the nature of our collaborations shifted heavily to these sorts of platforms. All of a sudden, the linear processes between stakeholders and PMs and designers and engineers and everyone else
collapsed into a handful of tools we were using to get our own jobs done.

Almost certainly, your design processes shifted to accommodate this new reality.

You might think that if you’re choosing to remain an IC, your job is crafting thoughtful designs, and maybe others will see your thoughtful designs and get better by osmosis.

But your task is more to craft thoughtful designers—whether that’s fellow design professionals on your team, or just the group of cross-functional folks working on this project with you.

Pretty UI won’t help you here—you’ll do this by empathetically delivering feedback that gets everyone more of what they want, effectively multiplying yourself.

You want people to want to work with you, specifically because you’re making them better at their job. Y’know, their compelling context.

You’ll need discipline to build skill and trust in this phase, but it’s worth the investment. Receiving and integrating feedback will help us avoid the extremes of being an untrusted jerk or a personality hire.

As you craft thoughtful designers, you build trust. Not only will the people who receive your feedback get better, others will see you giving that feedback and its effectiveness. They’ll feel a little more brave getting your input the next time,
regardless of the context.

But you do have to actually engage in critique to get better at it over time.

If you’re the type of person who says they want to “avoid politics”, here’s where that can start to go wrong. If you’re viewed as too sensitive to receive meaningful feedback, or too shy to deliver it, businesses won’t trust you with critical
projects, and they won’t bet on your big ideas.

Several years ago, I got the chance to work with a bunch of designers in an organic attempt to streamline rule-building interfaces across a bunch of different products with different tech stacks.

It was not easy. It took a lot of time and effort. It did not wrap up neatly with a perfectly-designed interface that everyone agreed with fully, nor did it result in perfect adoption across our products.

But it did show a lot of people what a small group of caring designers and accessibility experts and writers can achieve on their own, and how designers perceive opportunities that others miss.

And it taught all of us how to work together a little better, and gave us things to try the next time.

So when the next time rolled around and a group of designers needed to streamline complex builder experiences across an even broader scope, we built on past success.

The trust we’d build amongst a core group was able to spread to new group of 30 folks, and we ended up designing truly innovative interaction models that made accessibility a first-class consideration in builder experiences that often leave
such folks behind.

While we naturally had technical constraints and differences of opinion, one way we overcame them is by validating ideas in usability tests.

In one set of tests, we had customers bring their own content and asked them to reconstruct it fully in prototype builders. The success of a design was based on how successful users were with it—who cares if your builders are beautiful to
look at if people can’t use them to do their jobs?

This group produced incredible work together, and I watched some specific designers use the opportunity to grow their skill and build trust quickly.

Write off empathetic feedback at your own peril. You’ll be a less effective designer, and you’ll get deeper into your career wondering why you have trouble making a bigger impact.

It’ll be because you haven’t done the work to be trusted with bigger impact yet. Dig deep.

In this later phase—even with relentless imposter syndrome—you’ll have built up enough success (and failure) to have a little bit of confidence even in wildly complex or nebulous situations. You’re gonna need every bit.

At Salesforce, when our leaders have expressed the most valued aspects of a tenured IC, they consistently mention trusting that designer to go into an opaque-but-critical project that might have a lot of exec visibility.

Remember what we talked about earlier: you need the trust of others to get put into situations where you can put your skill to work.

When you do get a chance for broad impact, you’ll need to be ready to hit the ground running and experiment your way to whatever the project calls for.

You need to know how to put failure to work so that you can succeed faster—but you also need to know how to tell the story of that failure to others in a way that motivates them.

I’ve spent a long time working on marketing tools, but I was a musician for years before I was a designer or developer. I see so much of the world through the lens of independent music culture and music history, and it’s a part of me that has
nothing to do with my current day job.

Like many of you, I’ve worked on countless side projects over the years, which tend to integrate non-work interests. Back in 2012, a conversation with a dear friend led to a weekend project: a social album review app that got noticed by tech
press at Wired and Mashable, and we got flooded with thousands of beta signups overnight.

I’m telling you about it now because … it failed. We missed the opportunity. But we had fun anyway, and we learned a LOT—including how to take down a large hosting company’s servers.

Despite that, the spirit of the idea compelled us to keep up the project over the years. Under an evolving brand, we’ve put on local shows and we’ve built (and still maintain) an advertising platform for independent record stores. We turned
our app into a newsletter and then turned it into—surprise—a podcast, which has been running for years with a decent set of listeners and solid reviews.

In 2024, we released a 366-day calendar of recommended albums to listen to on specific days and expand your palette, and includes all the albums we’ve covered as podcast episodes.

The central thesis throughout all of it has been this: we as people can engage in meaningful, insightful critique of music without glossing over the complex history it evokes.

Every album has a compelling story, but there’s a way to tell those stories without devolving into speculation or conjecture or oversimplification.

As designers, we are certainly storytellers. That’s not a new idea. But the way that we tell stories about ourselves and our work will impact our influence long-term.

We often represent our process as a linear flow—even when we try to be honest with squiggles. Simplistic visuals can help us explain important concepts to non-designers—but they can betray both the underlying complexity of the problem
and gloss over the reality we’ve discussed: effective design often means intentional failure.

Early designers especially often imagine that more tenured ICs spend their time crafting compelling visions and narratives, which impress executives when delivered and lead to new projects getting funded and promotions handed out.

Being compelling is important and useful, but it will only get you so far—especially when business and money is on the line.

More important than telling compelling stories is telling true stories.

Engaging with complexity instead of smoothing out the story makes us better designers, and deepens the trust that others have in us.

When others see that you can methodically handle anything that comes to you and turn it into something valuable, they will want to let you do that more often. Everybody wins.

Once leaders see that you can predictably generate outcomes with diverse stakeholders and personalities, they will want to work with you, and will listen more often when you speak up. They can trust you in any environment to get results.

As you work on larger projects at bigger companies with people further up the executive ladder, your so-called design skills are much more about respectfully fielding feedback from stakeholders who might be aloof or naive about the
details. You may need to explain something very complex very quickly, on demand—or you may need to follow up individually for better impact.

Your job is to reverse engineer stated outcomes with noticeable consistency, and influence the people you need to influence to get the outcome everyone wants.

This idea has emerged for me recently—13 years into a Salesforce design career.

We’re slowly rolling out a very cool new version of our design system. I had virtually nothing to do with it, but my particular combination of expertise across design and front-end development and the Salesforce platform all helped me and a
few colleagues to see a gap in how we were implementing this new design system across our apps.

This gap illuminated a longstanding inefficiency in the design handoff process, and specifically how designs were translated to UI code.

Through countless conversations and increasingly complex experiments, we discovered new paths of working directly with our engineering counterparts to solve the problem and create a win-win situation for everyone involved.

We respectfully spoke truth about the inefficiency to our leaders, while using those experiments and outcomes to prove out a new idea. Sometimes we had to write a lot of code to prove a point. We openly collaborated with diverse stakeholders throughout that process to avoid any unintended disrespect of process or ownership.

Our willingness to experiment helps us build more trust and influence, as we guide the organization into new, more effective ways of designing products. But the trust from leaders to fix these problems—and my influence as an IC—comes
directly from the years of consistent, predictable outcomes.

As leaders learn that they can trust you over the long-term, you’ll get the chance to build influence with them, because they’ll know for a fact that you’re a valuable member of any project or effort.

So, where are you? Where are you going? And when should you be there?

How can you use feedback to keep yourself on track?

I hope I’ve provided some insight today on navigating a pretty opaque path. But even more so, I’m hopeful I’ve sparked some new conversations about what it means be intentionally IC.

I want to see you thrive in your career, and I hope you do. I can’t wait to hear all about it.