Senior Isn't About Your Tech Skills

Hi, I'm Swiss and today we're going to talk about how being senior isn't about your tech skills because your tech skills got you here, but they won't get you there. So what we're talking about is that a little bit of slope beats a lot of y-intercept. It doesn't really matter where you are right now. If you keep improving, you will eventually become as good as or better than all of the people you look up to.

So in the beginning, this growth is really easy. Every project is a learning opportunity. Every task that you get feels new and exciting. You read a doc, you read some docs or some blogs, and wow, everything is amazing. Everywhere you look, you're just learning so much. Once you get into books, there's so much good stuff in there.

But then as you keep growing, your growth slows down. You start reaching that plateau because it turns out there just isn't that much new to discover. And MCP is just another API protocol, Next.js, 10-Stack Start, Remix, they're all kind of the same. It's just the React framework. React server components are honestly very similar to how we used to do Ajax 20 years ago or what people are doing with HTMX on the Python side. And you know what? AI is fine, but honestly, you can learn enough to be dangerous in about a weekend or two.

So now what do you do? How can you start growing? One way people do this is that they just jump into a completely new stack, become a junior again, and learn everything from scratch. But it goes a lot faster than it goes your first time around. A lot of people start reading academic papers, seeing what academia is all about. But honestly, that can be a little depressing because it turns out we've been pretty much solving the same problems since the 70s. And the pendulum of back-end, front-end, sideways, whatever, just swings around every five years or so. And at the end of the day, we're just smearing complexity around. The business needs what the business needs. Users want what they want. And we're just smearing that complexity of the world in different places using slightly different technologies to solve very similar problems.

So the way you keep growing is by increasing your scope and your impact. Now, this is the soft stuff. This is about how you de-risk big ideas, how you break down projects, how you work with others. How can you offer more than just a pair of hands? Can you be the person that stakeholders come to to figure out what to do, not just how to do it? Can you give them advice on how to approach problems, how to solve really fuzzy, hey, we're not making enough money, how do we make more? Can you come into that environment and help there? It's the same tech, it's the same tech skills, but you're solving bigger and better problems. And the way you get there is by building trust, delivering results and empowering others.

Part of what this means is that you have to be effective, not just efficient. Until now, you were mostly judged based on whether you can do the thing. Can we give you a task and will you be able to execute, write the code and make it work? From now on, it's whether it's more about whether the thing you're doing was actually worth doing in the first place. What was the outcome of your project? How do you follow up after you shift to production? When do you consider your job to be done? Can we trust you to own a product, not just a project where a product means something that develops and evolves over time, not just something that has a start and a finish line? Can we say, hey, here is a product, here's a framework, a library that we use internally, or a user facing entire or an entire type of user or like a checkout flow or whatever, and you will just figure out how to make it better and better as time goes on. That's what being effective means over just being efficient. Because at the end of the day, if you run really, really fast, but in the wrong direction, that's not going to work. Richard Hamming has this really great quote, or he shares this really great observation in You and Your Research, which was a talk and then an essay, where he says that the difference between good researchers and really great researchers isn't so much how smart they are or how hard they work. It's about seeing where the puck is going and solving the problems that are worth solving. You can do really, really great work, but if you're not working with others, if you're not taking feedback, if you're not observing what's going on around you, 10 years later, you're still doing really great work, but somehow just nobody really cares because it's not the work that they are interested in. This is what people actually mean when they tell you that hard work doesn't get rewarded, because it's not about how hard you work, it's about what you got done. Nobody actually cares how hard you work. What they do care is what are the new abilities that your work has enabled for them. So it's about outcomes over outputs. Your outputs, so the code you write, the meetings you attend, the docs you do, the documentation you write, the strategies you design, all of that is just your outputs. That's the work product, the flower that you're creating. But what people care about, what stakeholders care about, what users care about, is what does this enable them to do. It's not about your code, it's about the superpowers that your code creates for others. And with this, you increase your luck surface area. The more superpowers you create for others, the more opportunities you'll get. So the amount of luck you have in your career, the amount of opportunities that come your way, is like the surface area between the outcomes you've created or the superpowers you've created for others. And who knows about it? It's not just how many people know about it, it's also who knows about it. You can go tweet some cool thing you've done to thousands of your Twitter followers or make a YouTube video. And yeah, that's cool. There's a bunch of randos on the internet who now know that you've done something a little bit interesting. But you can take that same thing and show it to five stakeholders or to five people who really, really benefit from it. And that's going to create much more luck. They're going to promote you internally in your company, they're going to talk about you outside of the company, etc. Luck just comes your way if you are giving other superpowers with your work and making sure that is really impactful for them. Because at the end of the day, people are going to forget who you grab drinks with on a Thursday night when you all went to happy hour and you wanted to schmooze around with others. They're going to forget that.

What they will remember is the person who empowered them to close that million dollar deal and get a huge bonus. And because if you deliver, the score is going to take care of itself. What this means is that the outcomes you create build trust. And that trust creates opportunities. This starts very small, even when you're just a junior engineer. It's like, hey, if we give a task to this person or to that person, which one of them is actually going to get done and deliver? That's the person who's going to get more scope, more responsibility and bigger rewards.

And it's like those memes say, good work is rewarded by even more work. And wait, that's bad. It's not bad. What you have to do is you have to leverage these opportunities that you're getting. You have to leverage the value that you bring to get the things that you want. You can, when you deliver and you, so delivering, being valuable, creating those superpowers for others, that's what gives you the leverage to then get more scope, more autonomy, more pay, more of whatever you want in your career.

I think Cal Newport calls this career capital. And what you actually get out of it mostly just depends on what you want. Some people take this career, this career capital and use it to chill and take, get like an easier role so that they can focus on their families, focus on their hobbies or whatever. Some people go full hog and they just use it to get more and more responsibility, more pay, et cetera. You can do whatever you want, but the first thing you need, the baseline that you want is to be seen as super valuable to your company, to be creating the, to your company and to other companies. We'll talk about that. You got to be creating that value because once you're valuable, you can use that to get the other things that you want.

So look, honestly, my, yeah, so like, here's an example from my own life. My HR title, so my official title has been senior engineer for like 10 years now. And that sounds bad, right? But it's not actually that bad. The job is completely different. 10 years ago, being a senior engineer for me meant that I can be given a task and I can execute, and then it's somebody else's problem to figure out if that was worth doing, if it's getting results, all of that stuff. I was just a, I was basically just a code monkey, a pair of hands that you hired, and I could execute for you independently.

But now, nowadays, the job is completely different. Whereas my boss used to tell me what to do, now he comes and asks me what we should do. I get to own entire parts of companies. I run teams. I mentor others. And the nice thing about that is that I make like four times more money than I did back then. I actually calculated just for these slides. It's, I think my total comp is three and a half times bigger than it was the first time I got the title senior engineer, same title, very different jobs.

And that doesn't mean that titles don't matter. Titles are very important if you work in a large tech company, or if you are not someone who looks like a white dude, if you are not someone who looks like a white dude, you need to have that title to open doors and be able to come talk to the right stakeholders. But there's a lot you can do with just being the person who takes control of the room and behaves like a senior engineer. And this is where it gets really tricky. Having those results on your resume, on your black sheet, if you want to call it that, that's also useful for your next job.

Having those results on your resume, on your black sheet, if you want to call it that, that's also useful for your next job. You can, if your current company can't give you what you're looking to get with the value you bring, you can take all those same things and go to a different company. Because people, when they look at resumes, they're not just, they don't know you. They're just, all they see is what have you done? What have you achieved? What were the outcomes that you created? And all of the social capital that you build inside a company can help you a little bit when you switch to a different company, but it's the results that really matter.

And at the end of the day, we all know who's the senior engineer in the room, right? It's like, look at this picture. It doesn't even matter if the more polished looking dude is the manager or has the fancier title, or is ostensibly in charge. We all know who's actually in charge. It's the guy in the crazy pants taking, being chill and who were like, you know what? I'm going to trust that guy to tell me where we're going and what we want to do because leadership. And that's what being a senior plus engineer is about a lot. It's the leadership that you take, how you lead projects.

Leadership is about creating direction in a sea of chaos. It's not just your title. It's not just the job that you have. It's about, okay, what do we need to do to get this project done, to get it delivered, to get it over the line, ideally within scope and under budget and on time. That's not always possible, but that sort of thing is what makes, that's what really distinguishes you as a senior engineer. And at this level, the higher you get in these levels, you might even have to go against what's immediately rewarded and aim for bigger goals. Just because your boss tells you, hey, we should not do any refactoring. We got to do this other thing.