Thriving as a Long-Term IC: Lessons in Influence, Growth, & Fulfillment

Cliff Seal at UXDX USA. Video: https://youtu.be/_CwBVAZoxzU

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Thriving as a long-term individual contributor

[00:00:07] And now I'm here to tell you all about it. Designers become managers of designers for a thousand perfectly valid reasons. Maybe you have in the past and switched back. Maybe you will in the future. And for all I know, maybe I will too. But I think until that day, our challenge is to figure out how to thrive as, as they call us, individual contributors. And by that I mean we want to keep the design jobs that we want to keep without losing our souls, brains or bodies in the process.

[00:00:36] Let me say this real quick before we hop in. I mentioned design managers. They do not have an easy job, for sure. But you do arguably have more source material to draw from to grow your career as a manager, whereas the IC path in design, especially in tech, feels really opaque. And so my hope today is to spark conversation in our industry around intentional paths to career growth for ICs.

[00:01:02] I've heard from a diverse range of colleagues and mentees over the years that I can be helpful in thinking about this and talking about it, and so I'm going to. But as best I can, I'm going to contextualize my experiences and suggestions to try to make them relevant to everyone, while pretty openly acknowledging the privilege inherent in my experiences. So I'm open to feedback on any blind spots about that. But I am really hopeful that what we discuss from here is going to help you in your career, no matter who you are. So let's start.

Balancing skill and trust

[00:01:35] I think to thrive as individual contributors, you'll need to intentionally cultivate and balance both design skill and the trust of other people. I think that skill is easier to measure, especially by non-designers, but the trust that you're building is just as critical. And if you're a self-centered designer, you're going to tend to overlook this balance, because you're going to miss a deeper truth: that effective design requires cooperation with other people, even if you're just one person designing one app for one other person to use. You can design an ideal visual interface all you want, but it's only actually ideal if you can get another person to behave in a specific way in relation to what you've done. So let's think about balancing these two ideas over time and how they lead to thriving long term.

[00:02:27] Right here at the top, I want to mention a helpful anecdote from author Simon Sinek. You may have heard of him. He was having a conversation with the leaders of an elite military force and basically said, how do you decide who's ready to do all this elite military stuff that's super important? And they drew a graph like this, with these axes, with skill and performance going up one side and trust going down the other. And they said, naturally, we don't want low trust, low skill folks. And naturally, we do want high skill, high trust folks. No surprises so far.

[00:03:02] But they added something that I think is really helpful for us: that this person, someone with high skill but low trust, is toxic to the team's success. They might be incredible at what they do, but they can't be trusted to do it, and they don't want these people on the team. They'd much rather have people with lower skill but higher trust. I think that's a helpful anecdote for us, because I would argue that that's probably true of many of our potential employers and clients and stakeholders, and even true of the type of designers that we want to work with ourselves.

[00:03:34] In that anecdote, Simon Sinek mentions that this toxic group is usually pretty identifiable even well outside of a military complex. As he puts it, most people can identify the [?] on their team. You're laughing because you just thought of somebody. Those of you who aren't laughing may consider who you are.

[00:04:00] So obviously then, in terms of this chart, we're going to want to go to the top right as soon as humanly possible. We want to be incredible designers with reliable success. We want the trust of everyone involved. We want them to implement our ideas. But I'm arguing today that how we get from the bottom left to the top right matters if you're going to thrive as an individual contributor. And while no one's path will be linear, what I do think you can do over the years of your career is calibrate where you are and try to point yourself in the right direction relative to the things that we're pointing out here as you go along. Asking for feedback very sincerely and practicing self-reflection is going to ensure that you avoid the undesirable corners of this chart.

[00:04:44] Some of you will still think today, maybe, that trust doesn't matter and you can be skilled enough to compensate for your lack of trust. But I'm going to tell you that I think you're going to be wrong, and I think you're going to pay for it long term in your career.

Three career phases

[00:04:57] Having fun with the buttons up here. So we're going to break this down into three really specific career phases. These are applicable across your entire design career, yes, but also inside of your current role. What I mean by that is even a very senior designer might be able to apply something that we talk about in the zero to one phase if you're in a new role or at a really small company. As we go along, I want you to try to calibrate and think about where you feel like you are in these phases of your career and role, and think about where you want to go over time.

[00:05:30] So let's start. Zero to one is a pretty helpful phrase that's emerged in recent years. Whether you're early in your career or just starting a new role, zero is always how it feels, and it always feels like you're trying to get something to one. To navigate those moments, I think it's really helpful to return to foundational elements of effective design, asking questions like: what are we actually doing when we design an experience? Why is someone paying us to do this? And how do we measure and improve success?

[00:06:01] Because whatever it is we're doing when we're designing, we're doing it together with colleagues and customers and users. Again, no design is successful unless it's producing a measurable outcome, even if that's just designing a banner ad to get clicked. And so to start building consistent success, you have to get really good at identifying the people who are involved in a given project, internally and externally, and then consistently influence their behavior by incentivizing them.

[00:06:29] For me, this whole idea became very real earlier in my career when I encountered a book called Badass by Kathy Sierra, who's an author otherwise known for wildly popular Java programming books. They read a little bit more like a graphic novel than a book. But this one in particular unwinds the entire concept of product design back into this really simple idea: successful design work produces tools that other people use to be good at something bigger and more compelling than the tool itself.

[00:06:58] What's cool about this is that that's not just a vague abstraction. It actually gives you a path to follow in design work, because our goal is to design experiences in such a way that our customers become better at the larger, more compelling context that they actually care about over time. And when you do that, accessibility and usability and designing for emotion, everything is wrapped up in this approach if you're thinking of it this way.

[00:07:25] I think here it's easy to think that career success as an IC means creating awesome products, and sometimes that is good enough to move your career along for a short period of time. But I think in the long run you need to see success differently. I think you're creating awesome users of a product who are leveraging it as a tool in pursuit of a goal that has nothing to do with you or the thing that you're building. Being an effective designer requires 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 from where they are to where they want to go. And when you do this, you actually serve the goal of everyone involved in your project, including stakeholders. Everyone wins when there are awesome users of a product that you're trying to sell.

Testing, diversification and iteration

[00:08:17] In this early phase, I think it's really tempting to go directly into this top left-hand 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 yet for anybody to expect anything measurable from you. So they're going to try to measure your output instead, and it's going to tempt you to optimize for it. But I'm encouraging you not to do that at the expense of building trust. The feedback that can keep us on the right track in this moment is user testing: something external that's validating that your design work is actually achieving its intended goal.

[00:08:55] So then with this feedback, keeping our ego in check, we're able to intentionally build trust through mutual success with increasingly diverse audiences. By that I mean different combinations of colleagues and stakeholders and users and customers. And just real quick: if you don't understand the power of intentional diversification, or you manage to write off what I'm saying as some sort of solely moral or political argument, you will not be a good designer in the long term. You will not build the knowledge or intuition that you need to produce outcomes at scale, because intentional diversification is a skill that's necessary for reliable user testing time after time. And the broader your overall coalition, users and customers included, the more confidence you can start to have about your outcomes at scale.

[00:09:47] At the same time, we're growing a complementary skill of iteration. You're never going to get it right on the first try as a designer, or the millionth try, because there is no perfect design. Instead, testing helps you identify weaknesses in your own design so that you can find them, prioritize them, and iterate them away without introducing new issues.

[00:10:10] If you keep your ego wrapped up in design work, you're not going to want to test or iterate, because it's going to feel bad to talk about how wrong you are so often. And you're also going to feel the pressure of getting everything right on the first try. I'm encouraging you to throw that entire idea out. To be effective, just reject the idea of a spontaneously crafted perfect design, and instead show your colleagues that the design process is a way to refine the value of an experience to the benefit of everyone involved, including the business. When you combine mutual success with valuable iterations, you can start inspiring entire teams to engage in that process.

Engagement Studio

[00:10:49] One of the coolest things I ever worked on with people was this thing called Engagement Studio, a visual automation builder for B2B marketers. This is a creative rendering of kind of where it ended up. But our team didn't start here. It actually started with our co-founder just asking us to redesign an existing product and saying, can you please make it more like Visio? That's reasonable enough directional guidance, but it started bringing to mind examples of things that we definitely didn't want to build in this moment.

[00:11:18] Free-form canvases for drawing diagrams have a lot of crossover with what we were building, but the relative complexity could be orders of magnitude apart. And on the other hand, a diagram is just a document. We were building a tool that let people take a whole lot of real actions all at once at scale, and possibly even loop them.

[00:11:39] What we did was we asked if we could have a couple of weeks to do research before we started redesigning. Because we had a small team of really smart people, we were able to do a lot in two weeks. We did a handful of interviews with diverse customers in their offices, and instead of asking them questions about marketing software, we asked them about diagramming and planning automations that they were already doing. Their homegrown visual languages had enough overlap that we could test and iterate our way towards a visual language that actually made sense to people. What was cool about that is then we knew that part was taken care of and we could concentrate on higher-level UX concerns.

[00:12:17] One of those, for instance: I mentioned that automation represents a whole lot of real actions taking place. Some of you may remember this from about a decade ago. This bit of Mailchimp UI got really famous because they sweated the details about this moment of sending an email out to potentially a lot of people, and there was a sweaty animated Freddie finger, and it met everybody in the moment really well. This was about sending one email to one list of people one time. And what we were building would let people do that exact same action dynamically at scale with billions of different combinations, and again, possibly loop it endlessly. At some point you still had to have the same sweaty moment to press go and make that work.

[00:13:02] To address this, our team eventually developed and iterated on a testing capability, letting people verify their automations by taking the journey themselves, and we added subtle animations and canvas zooming techniques to make the whole thing really engaging. We knew we were successful not only because people were successfully validating their automations and using this tool to do so, but on top of it we noticed that they enjoyed it.

[00:13:26] They came up with a name for this animated path. Different people who didn't talk to each other: one of them called it the yellow brick road, another one called it orange goo. Apparently they were having fun using a business tool. But what was really happening was it was giving them the confidence they needed to actually use the tool that we were giving them, and it was making them better at their jobs by making them better at using this tool. And the experience, like I mentioned, was polished enough that they were willing to adopt it really quickly.

The middle phase: crafting thoughtful designers

[00:13:58] So I think your skills will grow as you're willing to validate your own work. Your trust will build as you make teams and users and customers successful along with you, through your design contributions and non-manager leadership.

[00:14:15] So let's talk about the middle. As you enter this phase, I think that 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 is going to 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 is literally a skill issue, and you need to build that skill yourself, because you're going to need to adapt that skill to the collaboration tactics of any given moment.

[00:14:51] For example, I still remember exactly where I was when I first opened a design file that looked like this, which introduced panic into my life. Autosave changes and multiplayer and visual commenting. This was a huge shift from what we already thought we had settled on with Sketch, which was a huge shift from what we already thought we settled on with Illustrator, which was a huge... right? It's going to keep happening.

[00:15:12] But then something happened in 2020 that was pretty bad for all of us, and the nature of our collaborations shifted really heavily to these types of platforms. Any linear process that was left between PMs and engineers and designers, a lot of those things just collapsed into a handful of tools that we were using to get our jobs done. If you were a working designer at the time, almost certainly you shifted your processes to accommodate this new reality.

[00:15:38] You might think then that if you're choosing to remain an IC on purpose, that your job is crafting thoughtful designs, and then others will learn from your thoughtful designs by osmosis and become better designers, and everything else is up to the manager. I actually think that that's wrong. I think that your task is to craft thoughtful designers. Whether that's the fellow design professionals on your team, or just the cross-functional people who are working with you on a project who are cosplaying as designers.

[00:16:06] Basically, being good at making pretty UI will not help you with this. You can only do this by empathetically delivering feedback that gets everyone more of what they want and effectively multiplies your skill into other people, because you want people to want to work with you. And you want them to want that specifically because you're making them better at their job, which is their more compelling context.

[00:16:33] You'll need discipline to build skill and trust in this phase, but it's worth the investment. And again, receiving and integrating feedback is going to help us avoid the extremes of being an untrusted jerk or a personality hire. As you begin to craft thoughtful designers, you're going to build trust. Not only will the people who receive your feedback get better, others that see you giving that feedback and its effectiveness will also get better, and all those people will feel a little bit more brave getting your input the next time, regardless of whatever collaboration context you have.

Building trust through critique at scale

[00:17:10] But you do have to actually engage in critique to get better at it over time. If you're the type of person who likes to say that you avoid politics, here's where that's going to go wrong for you. If you're viewed as too sensitive to receive meaningful feedback or too shy to deliver it, businesses will not trust you with critical projects and will not bet on your big ideas.

[00:17:33] 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, across a bunch of different tech stacks. It was not easy, even though what we came up with was really cool, but it took a lot of time and effort. It didn't wrap up neatly. It didn't get perfectly done by engineering downstream. None of it was perfect. But it did show a lot of people what a small group of caring designers and accessibility experts and writers can achieve organically, and how design-minded people can perceive opportunities that others don't see. And it taught us all how to work together a little bit better in this context, so that we could maybe do a little bit better the next time.

[00:18:14] And then the next time came, and we had to figure out a way to streamline drag and drop builder experiences across an even broader scope of things. If you've ever worked on a builder, you already know what a headache this whole idea would be. But the trust that we built amongst the core group was able to spread to a larger group of like 30 folks. We ended up designing a whole lot of really cool stuff, including truly innovative interaction models that made accessibility a first-class citizen in drag and drop builder experiences that usually leave keyboard users behind.

[00:18:47] And while we naturally had technical constraints and differences of opinion, the way that we overcame them was by validating them in usability tests. Here you see one real test that we used. We were building, in this case, an email builder. We had customers bring in emails that they had already built and were already using, and asked them to build them in the prototype of the thing we were designing, because the only thing that matters is: can they use it? It doesn't matter if it looks nice in your slide deck to other people. That's how we managed to figure out how to move forward with a lot of this stuff.

[00:19:19] And the group produced incredible work together. But I also want to point out, I noticed several designers in particular who took advantage of this project to grow their skill and build a lot of trust really rapidly, which is something that you can do when you're willing to work with others well.

[00:19:37] Especially in this phase, you can write off empathetic feedback at your own peril. But again, I think you'll be a less effective designer. I think you'll get deeper into your career wondering why you're having trouble making bigger impact. And I think it'll be because you haven't done the work to be trusted with bigger impact yet. So I want you to dig deep if you're here.

The later phase: telling true stories

[00:19:56] So let's talk about this later phase. Even with relentless imposter syndrome, which I am currently experiencing now, you will have built up enough success and failure to have a little bit of confidence even in wildly complex or nebulous situations. At Salesforce specifically, when our leaders have expressed the most valued aspects of a tenured individual contributor, they consistently mention that they can trust that designer to go into opaque but critical situations that have a lot of executive visibility.

[00:20:29] So remember what we talked about earlier. You need the trust of other people built up over time so that you can get put into situations where you can put your skill to work. But then when you do get the chance for broad impact, you need to be ready to hit the ground running, not asking questions or permission. You need to experiment your way to whatever the project calls for. You need to know specifically how to put failure to work so that you can succeed faster. But I think you also need to know how to tell the story of failure to other people in a way that actually motivates them.

[00:21:05] For example, for my own life, I spent a long time as a musician, long before I was a developer or a designer. I see a lot of the world through the lens of independent music culture and history, and it's an important part of me that has nothing to do with my day job. And like many of you, I work out those important things about me through countless side projects.

[00:21:26] In 2012 I hit the 2012 jackpot. I built a social album review app with a friend of mine. It got noticed by tech press. It got picked up by Wired and Mashable. We got flooded with thousands of beta signups overnight. And I'm telling you about it now because absolutely nothing happened as a result of that. We totally failed to capture any attention that we might have had, or any opportunity that was in front of us. But we had a lot of fun and we learned a lot, including how to take down an entire hosting company's server pods and never be allowed in anymore.

[00:21:58] Despite any of that, the spirit of the idea compelled us to keep up this project over the years and under an evolving brand. We've put on local shows. We've built and still maintain to this day an advertising platform for independent record stores. We turned our app into a newsletter and turned our newsletter into, surprise, a podcast, which has been going pretty well for a while, has a lot of listeners and good reviews. Including in 2024, we even released a 366-day music calendar with a recommended album to listen to on a specific day every single year as a way to expand your palate.

[00:22:31] The central thesis of all of this is that we as people can engage in meaningful and insightful critique of music and art without glossing over the complex history that it evokes. Every album that we talk about has a really compelling story, but there's a way to tell that story without devolving into speculation or conjecture or oversimplification.

[00:22:53] And as designers, we're definitely storytellers. I'm not the first person to say anything like that, but the way that we tell stories, about ourselves even, and our work, will impact our influence long term, because we often represent processes as a linear flow even when we try to be honest with squiggles. Simplistic visuals can help you explain important concepts to non-designers, but they can betray the underlying complexity of the problem and gloss over the reality that we've discussed, which is that effective design usually means intentional failure as soon as possible.

[00:23:27] I think early designers especially imagine that if you stay as an IC long enough in your career, your job ends up being crafting compelling visions and narratives for the executive suite, which they fawn over and then hand out funding and promotions once you successfully complete that presentation. It's not really like that. Being compelling is important and useful, but it's only going to get you so far, especially when business and money is on the line. More important than telling compelling stories is telling true stories.

[00:24:00] Engaging with complexity instead of smoothing out the story makes us better designers, and it deepens the trust that other people have in us, because others will see that you can methodically handle anything that comes your way and turn it into something valuable, which will make them want to work with you. Once leaders see that you can predictably generate outcomes with diverse stakeholders and all the personalities that come with that, they're going to want to work with you and they're going to listen to you more often when you speak up, because they can trust you in any environment to get results.

Influence with leaders

[00:24:34] As you work on larger projects at larger companies with people further up executive ladders, your so-called design skills, I think, are much more about respectfully fielding feedback from stakeholders who are going to be aloof and naive about details. You may need to explain something very complex very quickly, on demand, in public, in front of people. Or you might need to have a follow-up personalized session with somebody to make impact. Your job is to reverse engineer outcomes with noticeable consistency and influence the people you need to influence to get that done.

[00:25:06] This idea emerged for me recently, 13 years deep into a role at Salesforce. We're slowly rolling out a new version of our design system, which is rad. I had nothing to do with it. But my particular combination of expertise across design and front-end development and the Salesforce platform helped me and a few colleagues to perceive this gap in how we were implementing it across our apps, which also then illuminated a long-standing inefficiency in the transition from a design getting turned into UI code. Some of you may have had that problem before.

[00:25:37] Through countless conversations and complex experiments, we discovered new paths of working with engineering counterparts to solve the problem at hand and create a win-win situation for everybody. We respectfully spoke truth about the inefficiency we were seeing to our leaders, but we used experiments and outcomes to prove out new ideas. We just point at it and go, that sucks. Cool, thank you. What should we do about that? Most people don't know. So we started finding a way to do that, and we used collaboration to make it work.

[00:26:11] Our willingness to experiment in moments like this helps us build more trust and influence, yes. But I also want to say directly, situations like this don't get handled at all unless you've built up enough trust over years for someone to trust you when you point out a problem and offer solutions for it. It takes a while to build that stuff up to begin with. But 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 that they put you on.

[00:26:47] So then, where do you think that you are, and where are you going, and when do you feel like you should be there, and how can you use feedback to keep yourself on track? I hope through this that I've provided some insight on navigating a pretty opaque path. But even more so, I'm pretty hopeful that I've sparked some new ideas and conversations in you about what it might mean to be intentionally an IC. I want to see you thrive in your career, and I really hope you do. And honestly, I look forward to the day where I'm sitting out there and you're standing up here telling us about how you figured this out for yourself. Thank you.

Q&A

[00:27:29] Host: Wow, Cliff. Thank you. That was incredibly empowering.

[00:27:32] Cliff: Thanks.

[00:27:34] Host: The typeface is also phenomenal. I feel like you've given us a lot to act on. Let's jump into some questions. Someone here is early in their career as a UX researcher and has lots of feedback to give, but no one is asking for it or giving them the authority to give it. Any advice on what to do in that situation? So maybe that's at the zero to one of your phases.

[00:27:55] Cliff: Oh, yeah. Oh, no. I love this. I don't know how much you'll love me for it, but you should write all of it down anyway. All of it, with dates and detailed information about everything that you would want to share. Even if you don't, and I totally hear you, you often don't have the authority to give it, no one wants to hear it sometimes. That's okay. You should still write it down.

[00:28:17] Cliff: Because what's going to happen is in a few years someone's going to come back to you and say, hey, shouldn't we have done this thing? And in your head you're going to go, yeah, that's the thing I tried to tell you about three years ago. But instead of having to figure out how to not say that sarcastically, you're going to pull up a document and you're going to say, let's look at what else we could figure out from here, because we figured this out three years ago in this test, so let's see what else we can improve at that time. And that'll help you gain some trust pretty quickly, because you'll be right, but not being a jerk about it, which is a good combo.

[00:28:47] Host: Absolutely. I like that you can also start to practice that even if you're not putting it into place. Writing down feedback is going to help you critique people better going forward. There's a question here from Michelle about their product manager who has started getting into Figma and making designs.

[00:29:03] Cliff: Oh, delightful. Love when that happens.

[00:29:05] Host: Should Michelle be asking them, or all of us if this happens to us, be asking them to stop doing my job, or be giving them feedback on their designs? What do you do in this situation?

[00:29:18] Cliff: That's a great question, Michelle. I would argue that making things in Figma isn't your job. If the PM can do it, it's not your job. I think you can find a way to work with them, because they found a new tool that excites them. This is the same as getting a new designer on your team who's never worked in a design team before and doesn't know what to do, but they're excited and they know how to use Figma. I think you can teach your PM and work with them collaboratively to use their energy around this a little bit better.

[00:29:52] Cliff: But giving them feedback on their designs, now we're agreed that's not your job, because it's not their designs. So being able to find a way to let them use the tool they want to use, that they're comfortable with, while also saying thank you so much for that, I really appreciate that you've given that to me, over here is the design file, I've integrated your suggestions, thanks so much, would you like to look over here at this one? I've been in that situation a lot, and so have a lot of other people. Trying to push hard often doesn't create the outcome that you want. You'd rather compromise a little bit. Let them get good with a tool and then figure out how to leverage that relationship differently in the future.

[00:30:34] Host: Absolutely. And there's a question here. I think for a lot of us, we might come to a crossroads in our career after we've been working for a few years: do you want to manage or do you want to stay an IC? There's a question here about if you've ever felt pressure to be a manager.

[00:30:47] Cliff: This is really good. Here's another moment where I'll just say really clearly, I can only speak for myself, I only have my own experiences here. I've been pressured to be a manager for at least five years. I just say no. That's the secret. No. Just write that down in your notebooks.

[00:31:08] Cliff: Obviously I have to do a good enough job to where they go, okay, we'll let you stay in that current role even if you say no. Sometimes that's why I gave the caveat at the beginning: I may very well become a manager one day, because you know what I like more than being an IC? Having a job. So if that's what I had to do, I would figure that out and I would try to get good at it as soon as I could. But I often encourage, especially designers that I mentor: you don't have to say yes to a management opportunity. You can, but you don't have to. And you can control what you want to do in your career as long as you feel sort of financially safe.

[00:31:41] Host: Yeah, the financial safety is a big piece of that.

[00:31:43] Cliff: Yes, it is.

[00:31:44] Host: All right, we're just about at time, so I'm going to ask a question. What's the music we should be listening to for today? What is the music on your calendar?

[00:31:53] Cliff: Oh, from today on the calendar, that's a very good question. I don't think I can remember it off the top of my head. But the most recent one I remember was Queen Latifah. So go back to anything Queen Latifah did in the 90s.

[00:32:05] Host: Oh, okay. Thank you. I heard an almost clap.

[00:32:08] Cliff: Yeah, you'll clap later when you listen to it. Chicago. Queen Latifah had some great songs in Chicago.

[00:32:16] Host: All right. Well, thank you, Cliff. This was phenomenal.

[00:32:18] Cliff: Thank you.