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

Cliff Seal at UXDX EMEA. Video: https://youtu.be/1QFG2lAXRz0

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 an individual contributor

[00:00:12] Hello. It's something like 8 a.m. my time, so let's go. Designers become managers of designers for a thousand perfectly valid reasons. Maybe you will become a design manager. Maybe I will too. Until that day, I think our challenge is to thrive as the individual contributors that we are. And by that I mean to keep the design jobs that we want to keep without losing our brains, bodies or souls in the process.

[00:00:44] Design managers do have a hard job, but they arguably have more source material to draw from to grow in their careers as people leaders. The IC path in design is pretty opaque, I think, especially in tech. So my hope today, sincerely, is to start sparking conversation in our industry around more intentional career growth.

[00:01:09] I've heard from a diverse range of my colleagues that I can be helpful in talking and thinking about this, through mentorship and other things like that. So 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 that there's some privilege inherent in my experiences. I'm open to feedback in that regard especially. But I'm hopeful that what we discuss from here is going to be applicable to everyone and help you no matter who you are.

Balancing skill and trust

[00:01:41] Let's start here, then. I think to thrive as individual contributors, you'll need to intentionally cultivate and balance both design skill and the trust of other people. Skill is easier to measure, especially by non-designers, but I think trust is just as critical. If you are a self-centered designer, you're going to overlook this balance, because you're going to miss the deeper truth that effective design requires cooperation with other people. Even if you're just one person building one app for one person to use, you can design pretty ideal experiences all you want, but it's only actually ideal if you get another human being to behave in a specific way in relation to what you've made.

[00:02:28] Let's think about balancing these ideas over time, and how they lead to thriving in the long term. As we do that, I want to use a helpful anecdote from an author named Simon Sinek. He was once in a conversation with the leaders of an elite military force, and said, "How do you even know who's ready to go out into the field in these super dangerous, critical, high-pressure situations?" They drew this graph.

[00:02:57] Naturally, they don't want low trust, low skill folks. No surprises. They do want high skill, high trust folks. Still no surprises. But they added something that I think is really helpful for us. 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. They'd much rather have someone with lower skill but higher trust. And I think that's probably true of many of our potential employers and clients and stakeholders, and probably even true of us and who we want to work with on our design teams.

[00:03:39] In that anecdote, Simon Sinek mentions that this toxic group of people is easily identifiable, even outside of any military context. Most people can point to the person on their team. You're laughing because you thought of someone just now.

[00:03:59] Obviously, then, in terms of this chart, we're going to want to get to the top right as soon as humanly possible. We want to be incredible designers with reliable success. We want the full trust of everyone around us to implement our ideas. But how we get from the bottom left to the top right matters if we're going to thrive as individual contributors. No one's path is going to be linear, but over the years of your career, what I think you can do is calibrate where you are and try to point yourself more in the right direction. Along the way, asking for feedback really sincerely and practicing some self-reflection is going to ensure you avoid the undesirable corners of this chart as you progress.

[00:04:45] Some of you will still be listening to me today and you'll still think that trust doesn't matter, and that you can just be a good enough designer with your skill to compensate for that lack of trust. But you will be wrong, and you're going to pay for it in the long term.

[00:04:59] We're going to break this down into three specific career phases. These are applicable across your entire career, but also inside your current role. What I mean by that is even a very experienced designer might apply some things we talk about in this first, early section if you're in a new role or at a really small company. As we go along, I want you to try to calibrate where you are. Practice that self-awareness. Try to find yourself in these phases of your career and role, and think about where it is that you want to go over time.

Zero to one: creating badass users

[00:05:32] Let's start here. Zero to one is a pretty helpful phrase that's emerged, I think, in recent years. Whether you're early in your career or, like I said, just starting a new role, it always feels like this. It always feels like zero, nothing, and you have to get somewhere and get to one. To navigate these moments, I think it's really helpful to return to foundational elements and questions about effective design work. What is it that we are actually doing when we design an experience? Why are we getting paid to do it? And how does anyone know that we're successful at it?

[00:06:09] Whatever it is that we're doing when we design something, we're doing it together with colleagues and customers and users. And like I said, no design is successful unless it's 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 really good at identifying the people who are involved in your success, internally and externally, and then consistently influence their behavior by incentivizing them.

[00:06:42] For me, this idea clicked into place pretty early in my career, after encountering a book called Badass by Kathy Sierra, who was otherwise known for writing wildly popular Java programming books. She writes books that look like this; it's more like a graphic novel than a traditional book. But this book specifically manages to unwind the entire concept of product design back into this simple idea: successful design work produces tools that other people use to get good at something bigger than that.

[00:07:16] The cool thing is that's not a vague abstraction. It's a path to follow in your design work, because our goal is to design experiences in such a way that customers become better at the larger, more compelling thing that they actually care about. When you think about things that way, accessibility, usability, even concepts like designing for emotion, are all wrapped up and contained in this approach.

[00:07:43] 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, I think you'll need to see success differently. You are creating awesome users of the product, who leverage it as a tool in pursuit of a goal that has nothing to do with you. Being an effective designer is going to 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. Creating badasses for their compelling context is something that gets everyone what they want, including your stakeholders, even if they wouldn't describe it that way.

[00:08:26] In this early phase, I think it's really tempting to go into that top left-hand corner, because you can impress a lot of people with polished design deliverables and working long hours. I'm from America; we love doing that there for some reason. But you haven't built up enough trust at that point for anyone to expect measurable outcomes from you, so they measure your output instead. That's going to tempt you to optimize for that, because it feels good, at the expense of building trust with other people. But I'm telling you, don't do that if you want to thrive.

[00:08:58] The feedback that can keep us on the right track here is user testing: something external that validates that your actual design work is achieving its actual intended goal. As we have feedback keeping us in check, we're able to intentionally build trust through mutual success with increasingly diverse audiences. By that I mean different combinations of colleagues, stakeholders, customers and users.

[00:09:28] If you don't understand the power of intentional diversification, and you write this off as some sort of moral or political argument, you're not going to be a good designer in the long run. You will not build the knowledge and the intuition that you need to produce outcomes at scale. Intentional diversification is a skill that's necessary for reliable user testing, because a handful of similar people can teach you a little bit, but what you really need to know is what happens across the board. The broader your overall coalition, the more confidence you can have about outcomes at scale.

[00:10:07] At the same time, what we're doing is growing a complementary skill of iteration. You are not going to get it right on the first try as a designer, or the millionth, because there is no perfect design. That's not what we're doing. Testing helps you identify weaknesses in your own design work, see them, prioritize them, and iterate them away without introducing new issues. If you wrap up your ego in your design work, you're not going to want to test or iterate, because it feels bad to tell people that you're wrong so often, and you're always going to feel the pressure of getting things right on the first try. Just throw that out.

[00:10:45] If you want to be effective, you need to reject the idea of a perfect, spontaneously crafted design. You need to show your colleagues instead that the design process is a way to refine the value of an experience, to the benefit of the business and everyone else involved. When you combine mutual success with valuable iterations, you can inspire a whole team to engage in that process, and things can really take off.

Engagement Studio

[00:11:12] I'll give you some examples today. One of the coolest projects I ever worked on was something called Engagement Studio, which was a visual automation builder for B2B marketers. This is a creative rendering from the marketing team of the UI that we landed on, and it shows where we ended up. But our team did not start here. It started with the co-founder of what was a pretty small startup at the time saying, "We need to redesign this existing thing, and I need you to make it more like Visio." If you're not familiar with that, I'll show you some screenshots in a second. When he said that, it was helpful directionally, but it started bringing to mind things that we definitely didn't want to give to marketers.

[00:11:54] Free-form canvases like this for drawing diagrams have a lot of crossover with workflow and automation mapping, but their relative complexity could be orders of magnitude apart. This is pretty wild. On the other hand, a diagram is a document. This is just a document, a file on a computer. And automation represents a whole lot of real actions taking place in the real world on behalf of your real company. We were even going to give you the ability to make it repeat and loop.

[00:12:26] So when we kicked off, instead of immediately redesigning, we asked for two weeks to do some research before starting the design. We had a small team of really smart people, so 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 what we were building and designing, we just asked them how they were already diagramming and planning their automations, because they were already doing this.

[00:12:53] These homegrown visual languages are real, from customers. They had enough in common to help us test and iterate towards a visual language that was successful with users; they understood what they were doing. And as we gained confidence that it was working, we were able to address higher-level UX concerns, which is what you always want to be able to do.

[00:13:13] I mentioned that automations represent a whole lot of real actions taking place, so let me contextualize that. You might have seen this little bit of UI from Mailchimp before, about 10 years ago. It got kind of famous in the design community through designing for emotion, and it was this cool moment of designers really sweating the details. It was a scary moment to send out an email, so there was this little animated finger with sweat dripping off it before you clicked the button. It was all really good. That was about sending one email, one time, to one list of people. We were building a tool that would let you do that same thing dynamically, in billions of different combinations, and repeat it. And at some point you still had to have your sweaty finger press the go button.

[00:14:02] To handle this, our team eventually developed, tested and iterated on a testing capability that let users verify their automations by taking the whole journey through themselves. We added these subtle animations and canvas zooming techniques to make the process itself engaging, so that people would want to use it. We knew we were successful not only because users were using it to successfully test and deploy their own work, but because we noticed that they enjoyed using it. This colored path would animate, and different people started calling it different things. One person called it the yellow brick road. Another person said the orange goo is following the path. They thought it was fun.

[00:14:46] It was giving them the confidence they needed to actually use the tool that we were giving them, which was in turn making them better at their jobs, because they were better at the tool. And because we made the experience pretty polished, they were willing to adopt it and try it pretty quickly. So your skills are going to grow as you're willing to validate your own work, and your trust is going to build as you make your teams and users and customers successful along with you, through design contributions and non-manager leadership.

The middle phase: crafting thoughtful designers

[00:15:17] Speaking of that, as we enter this middle phase, I think 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 with humility or deliver critique thoughtfully, that is literally a skill issue. You need to build that skill yourself, because you're going to need it when you adapt to the ways that collaboration changes, all of the time, over and over and over again.

[00:15:56] One example of that: I still remember exactly where I was when I opened a design file that looked like this, and I stopped breathing for a while, because it had autosaved changes and multiplayer and visual commenting. This was a huge shift from Sketch, which was a huge shift from Illustrator, which was a huge shift from Photoshop. Yeah, I've been a designer for a while. And then something happened in 2020 that was pretty bad for all of us, and the nature of our collaborations shifted heavily to these sorts of platforms. All of a sudden, anything linear that was left in the processes between stakeholders and PMs and engineers got collapsed into these handfuls of tools that we were using to get our jobs done. If you were a working designer at the time, almost certainly your process shifted to accommodate this new reality.

[00:16:46] You might think that if you're choosing to remain an IC on purpose, your job is crafting thoughtful designs. Maybe others will see your thoughtful designs and get better by osmosis, and everything else is up to a manager. I think your task is to craft thoughtful designers, whether that's fellow design professionals on your team or just a group of cross-functional people who are working with you on a project. Making pretty UI, things that look good, is not going to help you with this. You can only do this by delivering empathetic feedback that gets everyone more of what they want and effectively multiplies you as a designer. You want people to want to work with you specifically because you make them better at their jobs, which is their compelling context, by the way.

[00:17:38] You'll need a lot of discipline, I think, in this middle phase to build skill and trust. You've got to calibrate. But it's worth the investment. Receiving and integrating feedback will help us avoid the extremes of being either an untrusted jerk or a personality hire. As you craft thoughtful designers, you're going to build trust. Not only will the people who receive your feedback get better; others are going to see you giving that feedback and its effectiveness. Everyone's going to get better, and they'll feel a little bit braver about getting your input sooner the next time, regardless of the context or what collaboration platform you're using.

[00:18:18] 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 like to avoid politics, here's where that can start to go wrong for you as a designer. 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 they won't bet on your big ideas.

Rule builders and drag and drop builders

[00:18:44] Several years ago, I got the chance to work with a whole bunch of designers in an organic attempt to streamline rule-building interfaces across a bunch of different B2B business applications on a bunch of different tech stacks. It was not easy. It took a lot of time and effort. It did not wrap up neatly and perfectly with an excellently designed interface that everyone loved 100% and agreed with fully. It did not result in perfect adoption across our products. But on top of it being really good work, actually, it did show a lot of people what a small group of caring designers, accessibility experts and writers could achieve on their own, and how design-minded people can perceive opportunities in the products that other people don't really see. And it taught all of us how to work together a little bit better and gave us things to try the next time, because there's always a next time.

[00:19:34] The next time rolled around, and a group of designers needed to streamline complex drag and drop builder experiences across an even broader set of business applications and tech stacks. We were able to build on the past success, and the trust that we built amongst a core group was able to spread to a new, larger group of 30-some folks. We ended up designing, among other things, truly innovative interaction models, including one that I'm showing here. It made accessibility a first-class citizen in drag and drop builders, which usually leave keyboard-only users totally behind. It's just one of the many awesome things we cranked out.

[00:20:14] While we naturally had technical constraints and differences of opinion, we overcame them by validating ideas in usability tests. This is a real screenshot from one set of tests. We were testing an email builder with customers, and we said: just bring in an email that you've already built and use now, and then build it in our builder. Because it doesn't matter what our builder looks like. What matters is whether they could come in here and do their job using the tool that we're giving them.

[00:20:44] This group produced incredible work together. But I'm also pointing it out because I saw some specific designers recognize that it was an opportunity for them to grow skill and trust very quickly, and they did so. So write off empathetic feedback at your own peril. You'll be a less effective designer. You'll get deeper into your career wondering why you have trouble making a bigger impact, and it'll be because you haven't done the work to be trusted with bigger impact yet. So I think you've got to dig deep in this phase.

The later phase: telling true stories

[00:21:16] Now let's go to this last one. Even with relentless impostor syndrome, which I'm currently experiencing now, you'll have built up enough success and failure to have a little bit of confidence, even in highly nebulous situations, and you're going to need that. At Salesforce, where I work, when our design leaders, and even more leaders than just design, have expressed the valued aspects of a tenured individual contributor, they consistently mention trusting that designer to go into an opaque but critical project that's going to have a lot of executive visibility.

[00:21:55] Remember what we talked about earlier: you need the trust of other people in order to get put into situations where you can put your skill to work and grow it. When you do get the 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 quickly 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 actually motivates them.

[00:22:26] Here's an example. I've spent a long time working on marketing tools at this point in my life, but before that I was a musician for years, before I was a designer or a developer, for that matter, and I see a lot of the world through the lens of independent music culture and history. 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 that have nothing to do with my day job through countless side projects.

[00:22:53] This is one. Back in 2012, a conversation with a dear friend led to us building a social album review application. By the way, in 2012 streaming was a new concept; everything was different. We got picked up in the tech press by Wired and Mashable. We were living the 2012 tech dream. We got flooded with beta requests, all sorts of stuff. I'm telling you about it now because it absolutely failed. We did nothing. We totally missed whatever opportunity was there. But we had fun, and we learned a lot, including learning how to take down an entire hosting company's internal infrastructure by accident.

[00:23:37] Despite that, the spirit of the idea compelled us to keep up the project over the years, and under an evolving brand we've done so many things. We've put on local shows. 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, can anyone guess? A podcast. Yes, surprise. It's been running for years, and has a good amount of listeners and good reviews. We've done a ton of stuff, including last year, 2024, when we released a 366-day calendar of recommended albums to listen to on specific days every year, just to expand your palette.

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

[00:24:39] As designers, we're certainly storytellers. People love to say that. But the way that we tell our stories about ourselves and our work will impact our influence long term. We often represent our processes as linear flows, basically, even when we're somewhat honest with the squiggles about it. And this is cool: simplistic visuals can help explain important concepts, especially 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 means intentional failure.

[00:25:18] Early designers especially, I think, often imagine that ICs who have been in their job for 13 years are spending their time crafting these compelling stories that they present to executives, which everyone is impressed by, with beautiful visuals, and then the executives say, "Yes, yes, whatever you want," and they fund the projects and hand out promotions. No. Being compelling is important and useful, but it's only going to get you so far, especially when business and money are on the line. More important than telling compelling stories is telling true stories.

[00:25:50] Engaging with complexity instead of smoothing out the story makes us better designers and deepens the trust that other people have in us. When people 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, because everyone wins. Once leaders see that you can predictably generate outcomes with diverse stakeholders and the personalities that come along with that, they'll want to work with you and will listen to you more often when you speak up, because they can trust you in any environment to get results.

[00:26:30] As you work on larger projects at bigger 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 or naive about the details. You may need to explain something very complex very quickly, on demand, in front of a lot of people. Or on the other hand, you may need to give an individualized presentation to that person later on so they actually understand it. You've got to reverse engineer stated outcomes with noticeable consistency, and influence the people you need to influence to get the outcome that everyone wants.

Closing the design handoff gap

[00:27:04] This idea emerged for me recently, again 13 years deep into a role. 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 skill and expertise across design, front-end development and our technology platform helped me and a few other people see a gap in how we were implementing this new design across our applications. Seeing that gap also illuminated a long-standing inefficiency in the design handoff process, specifically how designs are translated into UI code. You've all probably had at least one moment where you're trying to figure that out.

[00:27:44] But what we didn't do is just point at it and go, "That sucks. That's bad. We should do something better." That won't work. Through countless experiments and countless conversations, we discovered new paths of working directly with our engineering counterparts, which solved the problem and created a win-win situation for everyone. In doing that, we respectfully spoke truth about the inefficiency to our leaders, while using experiments and outcomes to prove out a new idea. Sometimes we had to write a lot of actual code to prove a point. And when we did, we made sure that we collaborated with all those stakeholders throughout the process, to avoid unintended disrespect of process or ownership.

[00:28:31] Our willingness to experiment helps us build more trust and influence as we hopefully guide our organization into new, more effective ways of designing products. But the trust from leaders to fix these problems, and my influence as an individual contributor in this moment, come directly from the previous 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.

[00:29:05] So I ask you to try to place yourself. Where do you think you are in this? Where are you going? When do you think you should be there? And how can you use feedback to keep yourself on track? I hope that by talking through this I've provided some insight on navigating a pretty opaque path. But even more so, I'm really hopeful again that I've sparked some new conversation and thoughts in you about what it means to be intentionally IC. I want to see you thrive in your career, and I really hope that you do. And to be honest, I'm looking forward to the day where I'm sitting in one of these seats and you're up here telling me how you made it happen for yourself. Thank you.

Q&A

[00:29:48] Host: Well done. Wow. Badass, am I right?

[00:29:53] Cliff: I try.

[00:29:53] Host: Only one suggestion: you need a guitar riff when you...

[00:29:59] Cliff: Okay. Can we make that work, guys?

[00:30:01] Host: I am very tempted to just gush for five minutes, because this is not only valuable for ICs, it's also valuable for people that have to hire people. It's forcing me to realize some really smart hires I've made, and some really bad hires I've made in my past teams. And I will also tell you that some other design leaders and I were here earlier this morning talking about how many ICs seem unwilling to work on that trust part. So you've hit the nail on the head. We're going to get to the audience questions as soon as there are some, but I do want to ask a couple of clarifying things. What's a personality hire?

[00:30:37] Cliff: Cultural references are fun. A personality hire is someone who's not actually good at their job, but everyone likes them so much that they could never get fired.

[00:30:47] Host: Okay. Let's not assume the worst case, that people are in that category.

[00:30:51] Cliff: By the way, if you didn't think of anyone in your team, you might want to do some self-reflection. It might be you.

[00:30:59] Host: Might be you. Maybe you're headed that way. Any ideas on how to... you mentioned feedback, but how do you pull yourself back to the path? What's a good first step?

[00:31:10] Cliff: Testing is always the good first step. It's the canary in the coal mine, so to speak, about whether you're actually thinking about your work appropriately. In a lot of cases, people are already doing that, though. That's why I tried to mention as much as I could that you have to go talk to other people and get their feedback. You have to go ask them how you're doing. You have to actually listen to what they're saying. You have to actually remain calm if they tell you a thing you might be able to improve on, instead of getting mad or telling them they don't really know what they're talking about. Being able to have those conversations, especially with people who aren't your manager, who has a vested interest in your success, is going to help you stay between the boundaries a little better.

[00:31:52] Host: I hate to go off script, but I've got to ask this. We often associate designers with empathy. That's one of our superpowers, designers and researchers. And yet it seems like so many designers have a problem with that, with understanding the user that they have right in front of them. Have you seen that? Any theories? Why do you think that is, with people that are so empathetic?

[00:32:14] Cliff: The funny answer would be because they need to go to therapy. It's more true than you think.

[00:32:26] Host: ChatGPT will do that soon, so don't worry.

[00:32:30] Cliff: No. I think we've actually genericized empathy too much. I have to remind myself that product design especially is a pretty new career in general. It's a lot of why people haven't talked about being an individual contributor for this long. I think it's about being able to have a precise and deployable type of empathy, like when I talked about getting familiar with your users' and customers' larger, more compelling context. You have to, if you're going to be good at this. My leaders have told me, "You are good at this, and that's why I value you. I can take you from here and put you over here, and within a few days you'll have figured out what's important to the people that we need to buy that thing, and what it is that they care about, so that you can start thinking about what they need to actually get there." When we believe in a generic empathy, where it's just, "As a user, I'd like to use a product that I like," okay, you're not going to make it very long that way, because you're not helping people actually get better. Specific empathy, not generic empathy.

[00:33:36] Host: Thank you so much, Cliff. We really appreciate it.