I was a senior designer for about a year, and in my immediate working group there were two other senior designers who were friends of mine. They were a little bit older and further along their career than I was. One of them ended up becoming the first Staff at Coinbase that we had promoted internally, while the other became a manager. We were roughly in the same place in our career, and up until that moment, it seemed basically impossible to move up as an IC without managing. I didn’t even know what a Staff designer was. Then one of them became a Staff and I was “Oh shit, you can get promoted beyond level five as an IC!”

At the same time, I had the chance to observe my other friend gradually settle into the management track – just watching his workload shift in real-time, watching him peel off from problem solving for users, watching him peel off from thinking about design, and shifting to thinking about people and teams, doing the real and difficult emotional work that comes with that territory. It became clear to me that I had only wanted management for the forward progress, and not the actual work.

It was really formative to be able to watch these two paths unfold in front of me in real time. It’s often hard to calibrate yourself to people who are far down either path because they are so good at what they do it masks whether you’d actually like their job.

You kind of have to picture Coinbase at the time I was getting promoted. We had a relatively small design team, I think maybe ten-ish product designers and not a ton of management. It also was a time when we didn’t have a formal career ladder, which is part of the reason that I didn’t really think that going to Staff was possible because nobody ever went on to that level.

During that time, I was making a ton of things happen internally, advocating for the existence of projects, leading those projects to completion, running initiatives outside of my immediate product group around product quality, doing design sometimes, product management sometimes, writing, checking in some code...I was doing whatever was necessary to get things to happen that I felt were important – and frankly, I was deeply unhappy about it all because it felt like the org didn’t reward people for this kind of work.

Then out of the blue, Matt, my manager at the time, hit me with a promotion to Staff. He had this crazy multi page long doc making my case that to this day still dumbfounds me in how thoroughly it documented my achievements. So yeah, I don’t have a clean answer on this because it happened during a much more informal time at Coinbase, but if I had to guess, it was through a combination of making things happen that wouldn’t have otherwise, having a manager who believes in you, and maybe a tad of being so unhappy you’re ready to leave.

I think there are far more ways of being a Staff than there are of being a Senior. There’s a sort of well-defined Senior definition, which is that you are able to independently lead the design of large features alongside a PM and an engineering leader. Most senior designers that I know who are doing well, are doing that part well.

I think a Staff level is not as easy to define. Every Staff that I know is doing something pretty different. However, I feel there are two broad categories for how Staff are different.

First, they tend to work in, and lead, design systems. That’s where I’ve seen a lot of Staff promotions happen.

The other one is that they just work on very ambitious, cross-cutting, nebulous product design projects. This is typically like: here’s a large opportunity that we want to capitalize on, we have no idea what to do there, and you and this PM can go figure out what the product should even be. It’s a combination of doing research, writing docs, and getting organizational alignment.

In my experience, those are the two practical ways in which Staff levels are usually different from Senior.

I’ve done both actually. At the end of 2019, when I first became Staff, I was very much a product design person. I was advocating for the redesign of our home screen on the mobile app. And then I was leading the project because there was not really a PM on that project. For about a quarter that’s kind of the work that I was doing – ambiguous, difficult, cross-functional product design projects.

And then for the last two quarters of 2020, I was actually in the design system role.

I think that was especially salient for me as a design systems person, which is the last six months of my career. A design system is a little different because you’re explicitly expected to shape the process of how people interact with design systems. That’s part of the job. But it doesn’t change the fact that after all of the process work, you still need to be building stuff.

That was really exhausting for me. And I think it’s part of the reason why I felt really burnt out. I was expecting my main contribution to be in craft, but the reality of working on design systems is that craft is half of it. The other half is people work, governance process, contribution models, bringing people along...evangelizing all that stuff is part of the design system, but also often unplanned and under-rewarded.

And yeah, when I wasn’t on design systems, I did participate in a lot of hiring. I was on the hiring panel of most designers who are at Coinbase right now. So I’ve been on tons and tons of hiring panels because it felt like part of the job, even though there was never an explicit expectation. But I’ve since dialed back on that, because it just got to a place where I was burnt out. So now I’m on far fewer of them and am far happier.

No. It’s true that being a culture carrier is definitely part of the implicit job expectation for a Staff designer. They made you a Staff because they think that you’re a relatively competent person that others should try to emulate.

And so you have this sort of implicit expectation of role modeling or mentoring, and going to interviews and being the culture person is part of that. But for me, I felt I was never really graded on that stuff, which is kinda weird. It didn’t ever feel that was the official expectation for me, which made it easy for me to drop that work. I don’t know if that’s a good thing or not, but it certainly played out that way.

Has that affected how I view my job? I think I’ve just developed a far more realistic expectation of what I can and cannot do given my energy level. As a senior and a mid-level I was like “I’ll do whatever!” because the amount of stuff that was available for me to do was not that much. I had a limited amount of things that I was allowed to do, or that people expected me to do. So I could just do all of them!

As a Staff, people’s expectation of what you can do and should do grows a lot. Suddenly you’re no longer able to be in a place where you can say “Sure, I’ll do all of it!” You have to be pretty explicit about drawing your boundaries. You have to be able to say no to some stuff.

There are two things that I would pay attention to. One: what really gives you energy? And two: what is your organization’s readiness for Staff level roles?

It’s easy as a Senior and mid-level to kind of just say, “I’ll do everything because I’m ambitious and I want to succeed.” It can get to the point where you have a hard time telling the difference between liking success from doing a thing well versus liking the actual thing.

Personally, it prevented me from realizing that I didn’t like any of the management-adjacent work I’ve done. I just liked being told by other people that I was doing well.

So it’s really important to disentangle the thrill of success from intrinsic love for the activity and figure out for yourself: what do you actually like? Because the job just gets a lot harder as you progress up the levels, so you need to get that sorted out pretty quickly before you get burned out.

Yeah it’s always hard to tell what I like versus what other people tell me I’m doing well. You are only forced to realize it when the work really becomes too much. And then it’s a little late.

But there’s one version of this trap that’s even worse, which is when an organization nudges you a certain way because it needs someone there, but you don’t necessarily like what’s over there. You might want to find yourself a large juicy Staff problem, but the company just really needs to ship 15 small experiments.

In these cases, it’s important to assess your organization’s readiness for a Staff position. Depending on the size of your company, there might only be a limited number of Staff level problems available at any one time, or possibly none at all – which is almost never true by the way – but your org might believe that so you have to will your desired role into existence, which is doable, but definitely tough.

It’s hard because it’s hard to measure the value of craft. It depends on the culture you’re in. I’m sure there are companies out there that really deeply care about craft, where they reward people who are beacons of craft, but it seems exceedingly rare.

When it comes to perf, it’s hard to argue at most places that “I just did this experiment really, really well. And I’ve done the last 14 really, really, well too. Therefore my impact is equal to the person who is building the design system used by dozens of engineers and designers every day.” Unfortunately, it usually doesn’t work out for the craftsperson.

I’ve seen a lot of engineers struggle with this too, where building features well is not a path upwards, even if you did a ton of that. Staff engineers at Coinbase are also almost by definition platform engineers, and it’s just a different job. It’s the same in design, and I’m not sure how to fix that either.

I do it on the side. It’s sad, but my best-crafted work is always my side-projects. I’ve bumped against this wall where if I try to focus too much on the calibre of my individual craft at work, I would have to just accept that it would be a less expedient way to be promoted. Or, I’d have to convince people that craft is super important and it should be rewarded, so that I could subsequently do the work that I’ve advocated for.

There’s nothing wrong with it. It’s just really, really hard. I’ve tried it, and I’ve not been super successful at it. It’s possible, but it is really hard. You’re trying to change an organization’s culture in some sense, you’re trying to move this whole organization so that you can move up a little bit.

And it’s just a lot easier if you say “Hey, this is what the organization wants,” and you just go there. Overall it is less effort for the reward, you know? But again, it goes back to managing your energy. It’s easier to scratch that itch on the side than to try to move a whole organization.

The way that we’ve been thinking about this so far at Coinbase is that design systems is the center of craft. We are pushing most of the craft work into that team (that’s where a lot of the Staffs are!). And that’s kind of where you’re, in theory, supposed to be able to just really dig into the craft. That’s not 100% true yet, since the team is so young it spends a lot of time advocating for its own existence. But I think in a year, I wouldn’t be surprised if the people who really cared about craft are able to really thrive on the design system team. It’s definitely a long journey.

On the other hand, by doing this we’re setting the expectation that product designers are mostly focused on solving user problems, and less concerned with the actual craft of the pixels. I’m not sure that’s right either, but that’s kind of how it’s playing out right now.

For me, it feels you have to paint your job into existence at every level. I suppose you could be in a place where Staff level job expectations are super well-defined. Ever since I’ve moved to Staff, I’ve had to periodically say, “ok guys, this is what I think my job is now, and I’m going to write it down and then make sure that it aligns with my manager’s expectation.” And if I want to get promoted, I have to point at what I think the next level is, and then work on the plan to get there.

That part of the job was invisible to me until I got there. The guard rails do come off, but the trade-off is that you are responsible for defining the boundaries.

Both! The freedom is exhilarating. You feel you’re in this place where you can almost just decide that you care a lot about a certain problem, and then just go there and try to solve that. Now, it’s not always 100% true, but you certainly have far more freedom to do that as a Staff than as a Senior.

But then the other side is that then you have to bring other people along. You have to tell people that this is something that you’re interested in, and this is how it’s going to be impactful, and this is how it should be measured. So it is both exciting and extremely exhausting.

I think that’s kind of part of the job. I think it doesn’t have to be always this exhausting though. I think there could be a far more defined framework to support this kind of work so that you have to do less of the pointing of the job yourself and just go do that. But I think as it stands right now, you’re left on your own to define your job.

Nope. Nothing. We’re in the situation again where there’s nobody’s at the next level at Coinbase so I have to do this all over again.

Sure. At Coinbase, on the engineering side, I think there may be three, four Senior Staff engineers. There are none on the design side. If you just look by comparison, generally the difference between the Senior Staff and Staff is that they work on projects that impact more than one organization.

I think that’s kind of the common theme at Coinbase. If you’re Staff you’ve worked on cross cutting projects for your organization. As a Senior Staff, your work affects the company as a whole. That’s kind of vaguely where the line is, and if I was trying really hard to go to Senior Staff, then I would have to write up what I think the expectation is, show that to my manager, find agreement, and then start crafting my work to fit that bill.

But the reality is that I’m not trying to get promoted right now, so I haven’t really thought about that.

Well, part of it is personal. I just want to be a founder again, making stuff, and charging people for it. So I’m trying to conserve a lot of my energy for figuring out what the next thing that I want to build is, which means not spending it on Senior Staff promo planning.

But the deeper question is: why not? Why not keep going on this ladder and try to become a Senior Staff or Principal? For me, it’s because the degree of ownership starts tapering off.

I can’t confirm that this is 100% true, but the ownership that you have over an organization, both in terms of equity and actual control over your work, does not grow in proportion to your career as an IC. Far more decisions run through the management track than the IC track. So you’re in theory very impactful, maybe eventually as much as a senior manager or a director, but the reality is that you still don’t have a ton of control over what you’re doing. And for me it’s become really clear that what I value is control over what I’m doing and having ownership of the outcome. And the best way to get that is through creating a company.

I feel like there’s a really big missed opportunity in most organizations to pair a manager with an IC in a true partnership. If you look at the job of most managers...I don’t know how managers have time to think! Like if you’re a manager of managers, if you’re at a director level, are you supposed to think when you’re asleep? I just don’t know when the time is to actually strategize at those levels.

We expect folks in these positions to be great team builders, and somehow also generate extraordinary strategic insight. In practice, I think I’ve seen most of these leaders excel on the former while doing just “ok” on the latter.

But what if you had a person who is truly respected at a director level, but whose full-time job it is to figure out the strategic problems, and then partnered that person with a manager? I think that’d be far more effective for most organizations, right?

I don’t know why more organizations don’t work this way, but that’s kind of my dream of what an IC/manager partnership is: that at all levels, there’s person who’s explicitly, responsible for thinking about large strategic problems at that level and then a person who’s thinking about the people at this level. So if anything, I deeply believe in the value of a long IC ladder. I just think we still haven’t figured out how to make the most of folks on this track yet, probably because ultra-high leverage IC work is a relatively recent phenomenon (outside of finance, where you can literally have ultra high leverage) in the history of jobs.

That’s why I think this project is valuable. I hope you find someone who’s in this really strong partnership with their manager.

There’s a common trunk that my former PM, Anna Marie, calls the Dark Arts of the Organization. Across the board, no matter what kind of problems or what kind of focus you want to have as a Staff, you should be able to understand and influence: how do organizations decide things? How do they allocate resources? How do they value something? How do they decide what to do today or tomorrow?

As a Staff, you don’t have any formal power. You don’t manage people. You can’t reward or ding people for doing things. So most of what you do is use soft power to convince people that you are doing the right thing. Developing the skill of knowing who to convince and how to convince them is super important.

You want to understand how that stuff works and develop agency in this process. You want to be able to say “Okay, so I want to do this, so these are the people that I need to convince, at these forums. And for each person I need to convince, this is their network of trusted people that they will ask. And this is how I get those trusted people on board.”

Being able to map out the organization like this and see the tree of people, and knowing the nodes that you need to work on is a really crucial skill for ICs.

Yes, absolutely. For the last two years, I’ve had extremely ambiguous relationships with product management, and it’s been fine! I actually think that’s the best kind of relationship. For half of my projects, I’ve had no PM so I was both expected to be the PM and the designer. For the other half, I get to enjoy having a true thought partner where we’re able to fluidly travel back and forth between our respective areas of ownership.

That’s where the best partnerships happen. Not all PMs are receptive to that, but I’ve had the great luck of working with two PMs that were, and it’s been really great.

I don’t know. I really don’t know. I can try to guess...

For me, it’s kind of a joke, but growth feels like pain. I’m tuned to the pain of growth, and I think that’s the way that I’ve been able to tell. Whenever, for a long period of time, I don’t experience any kind of pain or embarrassment, I feel I’m not growing.

Yeah, a little bit. You’ve got to be a little bit embarrassed to know that you have room to improve, right? If you’re not ever embarrassed, I think you’re not growing anymore. So for me, in my current role, I’m always pretty embarrassed.

Every couple of weeks I say “Oh, I probably should have known that.” And when that thought occurs frequently enough in my head, then yeah this is probably still challenging for me.

It’s not the same everywhere, because not all organizations treat the titles the same, but for me at Coinbase it’s been pretty helpful. We’ve grown in two large growth spurts. In 2018 we hired a couple hundred people. And then in 2020, we’ve hired a couple of hundred people. And so we have these large growth spurts where a lot of people join, nobody knows what’s going on, and nobody knows who does what. And especially while we’re remote, being able to open a Slack portrait, and then look at a name, a title and an organization helps to answer: “How should I interface with this person?”

They’re the meat API, you know? So having it be clear – “Staff designer on this team” – someone would suddenly know that if they have problems about this team that are craft related, or design related, then this is probably a good person to go to. So it’s a really useful shorthand for growing organizations to have titles that roughly reflect what you’re doing.

They just set people’s expectations for how they should work with you. That does a lot of work in and of itself, because otherwise you would have to set that expectation yourself.

Yeah, that’s definitely a trade-off that I recognize too, where sometimes I feel I’m given too much power on some random decision because people just expect you to have opinions on things as a Staff designer. Sometimes you have to explicitly advocate for other people. “Yeah, you looped me in on this and I’m a Staff designer technically, but I don’t have any opinion on this. You’re better off talking to this other person.”

It’s been really hard for me to practice hard skills during work. I’m always at a place where I will practice the exact amount of hard skills required for me to solve a problem. And I think the job expectation right now for me has just grown to a place where I feel guilty for spending a ton of time investing in hard skills that may not immediately pay off.

Because there are plenty of other things that I could be doing right now to have an impact on this organization. Cultivating a set of hard skills that are not impactful within the quarter is tough to invest in. And you have to actually write out the case of why investing, you know, 20% of my time is a good idea over the next two quarters, even though we can’t see the immediate payoff.

When you’re a little bit earlier in your career, people don’t have that many expectations for you. And so you can just go in, take some time to invest in those hard skills, and people won’t question it.

But I actually think it’s a huge deal to have a really polished set of hard skills as a super senior designer, because that’s literally your trade. If you’re not really up on the hard skills, what’s the point?

I don’t really have a good answer on when you’re supposed to polish your hard skills and get better at those. I think that the real answer is: on your own time, because you like what you’re doing. And so that’s kind of what I’ve been doing. I pick up things on the side by doing side projects and reading because I like this job and this industry.

It shouldn’t have to feel this way, but I don’t really have an answer for how it doesn’t feel this way.

That’s the answer so far and it’s not good. I mean, I think that the more explicit answer is that you write a doc saying, “this is why I’m willing to invest in these skills and this is how it’s going to pay off.” And then you defend the time to do it. But it’s just that it takes so much intentionality to do that, and you can forget to do that.

Clearly not enough because I’m pretty burnt out. I mean, most people probably are in 2020.

Yeah, that’s right. Until the vaccine, I’ll still keep using that excuse.

Okay. So it can feel isolating pretty quickly as a Staff designer, especially if you’re working on one of those rabbit hole-y problems where you quickly become the only person with the full context on it. And I think there are two things that happen when you’re deep in the problem:

One, you forget to ask for help. You’re often at a place where you say “Oh, man, asking for help means that I have to explain all of this to you.” So it can feel like you’re on your own and you’re supposed to just solve everything. That’s just not true. That’s one of the things that I tripped on a lot: I didn’t know how to ask for help.

And I didn’t know that knowing how to ask for help is part of the job! It felt to me in the beginning that “Oh yeah, well, they gave you this big job, and they gave you this big expectation, and this big pay, and now it’s your job to figure everything out.” But the reality is that half the job is actually figuring out who is the best person to help you. And the answer often isn’t you. And that’s okay. It’s not a failure on your part.

And I think the other thing is that it’s really worthwhile to invest in bringing people along, even though there’s no immediate payoff. I’ve made the mistake of not broadcasting what I’m up to and why it’s important; all the managing up and managing sideways, right?

Things always take far more time than you think, and it takes far more people than just you to work on it. So early on, being intentional about broadcasting my work so that people passively have context on my work, can save a lot of pain later when you’re feeling alone or need help. It’s something that I’m learning just now.