Swizec Teller

SE Radio 515: Swizec Teller on Becoming a Senior Engineer

This week, senior software engineer, instructor, and blogger Swizec Teller spoke with SE Radio’s Brijesh Ammanath about the “senior mindset.” Becoming a senior engineer is about more than just years of experience but rather about cultivating a different way of thinking. This episode offers insights into what it takes to become a senior engineer, including themes of learning, mentorship, influencing, leadership, performance management, growth, and career path. Understand the key traits and behaviors of senior engineers and the mindset with which they approach problems. Learn to improve your teaching skills by using an iterative approach that’s similar to development. Understand how codifying best practices frees up engineering time to focus on the hard challenges. Dig deeper into leadership and understand how you lead and influence teams that you’re not managing directly. Finally, consider how the timeboxing technique can help you to focus and get into the flow state.

Show Notes

Related Links


Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Brijesh Ammanath 00:00:18 Welcome to Software Engineering Radio. I’m your host, Brijesh Ammanath. And today my guest is Swizec Teller. Swizec is a senior software engineer, instructor, blogger, vlogger, conference speaker, and author. His career in high-growth San Francisco startups changed how he thinks about code, and he’s sharing those lessons in his Senior Mindset Newsletter. He’s currently working with Tia as a senior software engineer. He has published several books and video courses, including React for, Serverless, Data Visualization, D3.JS, Serverless, and Why Programmers Work at Night. He has trained the engineering teams for multiple fortune 500 companies on React, Redux, GraphQL, Serverless, and other modern web technologies. Swizec, welcome to Software Engineering Radio. Is there anything I missed in your bio that you’d like to add?

Swizec Teller 00:01:24 Hey, thanks for having me. That’s a surprisingly comprehensive bio. I think you got literally everything I’ve ever done.

Brijesh Ammanath 00:01:31 Excellent. In the episode today, we will cover various aspects about being a senior software engineer. We will start by covering the basics and then move to cover influencing, leadership, mentorship, learning, performance management and career path. So, let’s start with the basics. How do you define a true senior software engineer, years of tenure, job title knowledge? What matters?

Swizec Teller 00:02:00 Honestly, I think the years of tenure are probably the least correlated with you being a true senior software engineer. You see this a lot, especially in quickly growing companies where people just for sticking around get a senior title because, you know, you’ve been with the company for a couple of years; they have to do something. And so, what we get is this title inflation where I’ve now heard stories of even people getting the “senior engineer” title, but from being hired straight out of college, just because they have college experience. It’s getting kind of weird really, but I think that’s great. I think if you do get the title, I would definitely take it because it does help your career. Titles help your career, and that’s why we give titles out. And it’s always nice to get a title, but I would say that once you have that title — or if you want to get that title based on merit, rather than just years on the job — I would focus primarily on how you approach solving problems.

Swizec Teller 00:03:02 And I think the challenge that a lot of people run into as engineers, we like to get really focused on the engineering aspects and the coding aspects. And we kind of forget about why it is that we do engineering and why it is that we write code. And I think that the more senior you get, the more you become focused on using code as a tool to solve problems and to achieve business results rather than code for its own sake. So, I would say that that’s the main difference between someone who’s a mid-level or junior is that they’re more focused on the code and how to actually do the thing rather than later, when you are more senior, you become more focused on the problem solving and the business stuff, and writing the actual code is almost like — I wouldn’t say exactly an afterthought, but it’s just the final delivery of the actual engineering process that happened before.

Brijesh Ammanath 00:04:00 Right. And is that what you mean by the “senior engineer mindset?” You know, are those the identifiable behaviors of a senior engineer?

Swizec Teller 00:04:10 Yeah, exactly. I would say that the main identified behaviors of a senior engineer are this relentless focus on solving problems rather than writing the code and something that you often see in this transition is people starting to say that they don’t care about the code or that the code itself doesn’t really matter. Obviously, it still matters to an extent you don’t want to write code that’s going to be impossible to maintain, but again, there’s a trick there because you’re not focused on the code itself being perfect. And the craft of writing really amazing code you’re focused on the business problem or the business metric of maintainability, because you’re going to have to evolve the code over time. I think the main difference really is that the Senior Mindset, at least to me, means that focus on using code to solve problems, rather than thinking about the code itself as like a craft. It’s still a craft, but it’s the purpose is not the craft. That’s what hobbies are for. And that’s what site projects are for when you’re coding in a business context, the business is the actual thing you’re thinking about.

Brijesh Ammanath 00:05:22 Okay. So, you are focusing on solving the business problem rather than building the best solution, which might not be the best fit for solving the business problem.

Swizec Teller 00:05:32 Yeah, exactly. That’s a really good way of putting it because you see this a lot in startups, I’ve been playing around with advising some startups in the very early stages, or you can see at outside projects as well. What often happens is that engineers get so focused on, oh yes, this is a nice Greenfield project. We’re going to make everything perfect. We’re going to design the perfect framework. We’re going to find the perfect library and we’re going to spend multiple weeks or months making sure that this is really amazing. And they completely forget that even if you build the best code and there’s no users for it, you’ve just wasted a bunch of time. What you really should do is make a solution that’s fit for the current stage that you’re at, get it out quickly, get feedback from the market and then improve it. Because whether you spend a week building something or you spend two months building something, I can almost promise you that the first solution that you build is going to be wrong. Regardless of how long it took, regardless of how much thought went into it, regardless of how many blogs you read or how many books and how perfectly you designed it, the first solution is always going to be wrong.

Swizec Teller 00:06:48 So it’s much better to get it out quickly and figure out the right solution first. And then when you know the right solution, then you can think about how to polish it up and how to make it better, how to make it easier to maintain more architecturally correct, et cetera. Cause the other thing that comes with that is also, at least for me, I don’t know about the listeners of this podcast, but for most of us, you know, we are not Google. We’re not dealing with the kind of scale where you have billions of users using your software every day. So, you can get away with not being as tightly engineered as Google. You know, it’s same as when rocket scientists are building a rocket ship at SpaceX, that’s going to cost, I don’t know, a hundred million dollars when it blows up and doesn’t deliver payload to orbit. That’s a very different engineering criteria than when you’re building, let’s say that Colin Furze (?) guy who builds really cool things on YouTube. And he built a rocket powered go cart or rocket powered sled that he used in his backyard. Very different engineering criteria and I can promise you that if Colin Furze was building with the exact same engineering practices as NASA or SpaceX, that video would never come out because he would still be working on it 10 years later.

Brijesh Ammanath 00:08:09 In one of your blog posts, you have said a senior engineer works as a force multiplier. Can you expand on this?

Swizec Teller 00:08:19 Yeah. So the force multiplier concept, I think originally comes from the military or the Navy, but the idea is that first multipliers are the kind of people that you put on a team and they make everyone around them work better, perform at a higher level. They make the whole team just better at delivering projects, at delivering work. So, what often happens with senior engineer is that the kind of problems you’re solving start outgrowing the amount of work you can do yourself. This is even an example that forget who the author is, but the mythical man month where it’s a whole book about working together as a team and about how the most famous quote from that book that everyone remembers is adding engineers to a late project, make project makes the project even later. So what they take out of it is, oh, if adding more engineers makes projects slower, then I’m just going to be the superhero who gets everything done.

Swizec Teller 00:09:22 And it’s amazing. And like, I’m going to have low communication overhead. I’m going to be able to think of everything on my own and I’m just going to deliver this amazing code and it’s going to be great. And that’s true. It is much easier in a lot of cases to work on your own. But the other part of that book that a lot of people ignore is that he says, yes, a single, super talented engineer can work faster because they don’t have communication overhead, but there is a limit to how much you can actually just even just typing on a keyboard takes time. So a single engineer is never going to be able to deliver a software project like an operating system or a modern web app that runs like a hundred million dollar business. It’s just, I mean, you could, it’s just going to take you 10 years.

Swizec Teller 00:10:14 And if it takes you 10 years, the market’s going to change by then and nobody’s going to care. So come back to the force multiplier part. The way you can take that into your own career is to embrace the idea that modern software development is a team sport. And you can be the person who makes everyone on your team faster because a team that has one 10X engineer and five 1X engineers kind of milling around not doing anything, is going to be much slower than a team that has a one 5X engineer. And that 5X engineer decides to spend most of their time getting all of the other engineers to be, I donít know, 2X or 3X, because if I got my math right, 5 + 15 is more than 10 + 4.

Brijesh Ammanath 00:11:05 Right, we will touch more about, you know, building that high performing team. But right now they’re going to transition into learning and we’ll touch on some aspects of the importance of continuous learning. As a senior engineer, you get pulled in multiple directions, multiple projects. How do you find the time to learn? How do you keep motivating yourself, pushing yourself to learn something new?

Swizec Teller 00:11:29 I love that question because most of the engineers I’ve met, I would almost rather tell them to stop learning so many new things and try to focus on a few things a little bit more. Because one thing that happens is that, especially when you are reading a lot of, a lot of stuff online, is really aimed at beginners and juniors. So what happens with many senior engineers that I know is that, they are juniors in 50 different technologies instead of knowing about 50 technologies and being able to pick them up if they get there and then being really deep in one or two. And this is kind of tricky because going really deep in one technology, or maybe even five technologies, if that’s what you like, is a better bank for your buck than learning the surface of everything. But knowing the surface of everything is kind of useful because it helps you jump around.

Swizec Teller 00:12:27 So you ask me more about the motivation and finding the time. I don’t think it’s really something you should make time for because you know, we’re not really at school anymore. If you need to make time to learn something, it might not actually be worth learning. I personally much rather go where my interests take me. If I find something interesting, I dive in and I explore and I try to figure it out. If I run into a problem at work, that’s a really good time to be like, Hey, I found this problem and I have a problem that I want to solve, which is really good motivation to learn how to solve that problem. Especially if you’re a senior engineer, you can very often find yourself in a situation where you are pretty much the world’s leading expert in that specific issue in your specific company, in your specific situation, there will be times where you look around you and there’s nobody on your team.

Swizec Teller 00:13:29 You can ask for help. There’s nobody on the internet who has ever solved anything like that. You can find people who’ve solved something kind of similar, or you can find other experts to talk with who have, who are just really good at thinking through things. But you’re kind of just going to have to push the edge of human knowledge a little further in that regard. And I find that to be a really good way to learn it for me as well, because it’s like solving the problem is the motivation part, figuring out the solution is the learning part because you’re learning how to do something new. And with some luck, you’ve also learned something that nobody else in the world has figured out before, or at least not in your particular situation. And then if you write about it, you can make it easier for others as well.

Swizec Teller 00:14:15 And the writing about it, I find is really useful to help you clarify your thoughts and really cement the knowledge like explaining it to an audience really helps you clarify it to yourself. And it’s a good hack to find blind spots in your reasoning. Like, one thing I like to say is that every senior engineer, when they make a decision should really be able to explain why they made that decision. And if you don’t know why you made a decision, there’s a very high likelihood that there’s some part of your process that you don’t fully understand yet. That would be good to begin to and learn more about. Yeah. Does that answer your question?

Brijesh Ammanath 00:14:57 It does. Yeah. I think if you are motivated enough and passionate enough about something, you know, you do find the time. That’s what you’re trying to say.

Swizec Teller 00:15:05 Basically you find the time and making the time for that at work is actually part of the job. I think a lot of engineers are afraid of learning on the job, but the job isn’t banging out perfect code, the job is solving problems. So if they give you a problem, you don’t know how to solve, learning how to solve it is actually part of the job. And so completely something you should be doing on company time. And I think that also makes a lot more time than people have on nights and weekends around the job.

Brijesh Ammanath 00:15:40 Okay. How important is coaching and teaching for a senior engineer?

Swizec Teller 00:15:46 I think it’s a big part of the job, actually. If youíre like, that’s part of the force multiplier thing we mentioned earlier is that when you are on a team and you consider it part of your role to make everyone on the team better, faster, just more efficient at solving problems, giving them that mentoring and perspective is a big part of it. So I think everyone who’s a senior engineer should at least think about mentoring others and coaching them. And the other aspect is that it frees you up to more interesting parts of the job. Like one thing I try to always focus on when I join a company or whenever I accept a project is I’m trying to work myself out of that role or work myself out of that job. Because if you are the only person in the company who can solve a specific set of problems, then you will always be the person who is solving those problems and you can’t take vacations.

Swizec Teller 00:16:50 You canít leave the team. You canít go on to solving more interesting problems. And if you train others to solve those problems, or if you just help them along, if you encourage them, Hey, you go do this. I already know how to do it. I’ve done. I’ve built a login form 50 times in my life. Why don’t you build this login form and ask me questions and I’ll help you out. And that way, the next time that you have to build a login form, there’s not two people on the team who can do it and you can keep working on something that you find more interesting rather than something that you’ve been doing forever.

Brijesh Ammanath 00:17:24 Teaching is a completely different skill set compared to cutting code while someone actually good at instruction, not everybody is. How do you improve your teaching skills?

Swizec Teller 00:17:36 I think with teaching skills, it’s one of those things that you just have to do. If you jump in and start teaching and the more you do it, the easier it gets. And you know, it’s totally fine to run experiments. Not every time you try to explain something it’s going to stick. Not every time is going to really resonate with the person and different approaches, resonate with different people. So what I personally try to do is kind of try different things with different people. I often, if you go through my logging catalog, you’ll see that I have a lot of articles that are roughly on the same idea because I’m developing the idea over time. And I’m also figuring out how to explain the idea, how to talk about it in a way that resonates with people. And you can do the same when you are mentoring at work.

Swizec Teller 00:18:28 You can try just throwing somebody in the deep end and see if they ask you questions. If they’re not the kind of person who has questions, you can instead try to next time, they pick a task that you don’t think they’ll be able to do. You ask them, Hey, let’s meet together. Let’s figure it out. And then we’ll collaboratively come up with a solution. And then you go off and you code it, or you can use PRS and like pool requests and code review are also a really good approach for teaching where somebody makes a draft of a solution. They, they solve it to the best of their ability and you can then go in and give them, uh, pointers and be like, Hey, this could be done differently and explain your reasoning why it should be done differently. Because like the core of my teaching philosophy is to always try to explain my reasoning behind why I’m giving a suggestion, because that way over time, people get more exposed to my reasoning.

Swizec Teller 00:19:21 They can start reason in similar ways on their own. And next time they won’t have to ask or they’ll just do it a better way the first time, because they know the reasoning or this also happens. Sometimes they can just be like, Hey, Swizec, this reasoning makes no sense. I’m not going to make the change you propose. And that’s fine because it means that I was most likely wrong. If I can’t explain why I think something should be done a different way, or if my reasoning doesn’t actually match reality, like I had an assumption that isn’t actually true. That’s totally fine. That’s what collaboration is all about. But yeah, I think fundamentally getting better at teaching is mostly about trying and seeing what sticks. And it’s also a very humbling experience because you very often learn that you don’t actually know what you were talking about, and that gives you those pointers for what we were saying earlier for jumping into and learning more things like, Hey, I just said, this should be done differently. I’m not actually able to explain it, which means maybe I don’t understand it as well as I thought I did. So I’m going to go read an article about it, read a book about it, and I’m going to learn more because of that.

Brijesh Ammanath 00:20:33 Interesting. Iterative development is something which is quite well established in software development. It’s interesting to hear about iterative teaching as well. So yeah that’s something which I’m sure our listeners will learn from. Over the course of your career you get to know about many best practices and make many of these part of your development regime. It’s just the way you develop or build software. Have you seen any instances where these best practices have been codified? What challenges are faced in ensuring the entire team adopts these best practices?

Swizec Teller 00:21:10 Oh, that’s a really good question. So I think there’s kind of different levels of codifying best practices. So I think the first level of codifying a best practice is figuring out what is the best practice. This goes back to what people say, don’t make an abstraction until you’ve done something two or three times, because those two or three times actually inform what the best practice is going to be. You have to see how something works for a pattern to emerge. Then when a pattern emerges, what you can do is codify that pattern by either showing it to the rest of the team and being like, and saying, Hey, you know, here’s something that has really worked for me. It has worked in these multiple instances. Maybe you should try to, and then if people try it and they like it, it’s going to become, it kind of spreads almost like a cultural idea within the team.

Swizec Teller 00:22:07 The good practices tend to spread on the team fairly organically. Everyone adopts them because they’re also helping them. If it’s just a good practice that you read about somewhere and it doesn’t resonate with your team, it might be because it might be because it’s not actually working for your team. Or your team is not at the point yet, or the company isn’t at the point yet where that best practice makes sense. Like for example, a lot of the things that Google does, don’t make sense for my team. Who’s like 30 engineers because we don’t need the overhead process that thousands of engineers at Google use, because we’re just not big enough. And we would spend more time following the best practices than we actually get result out of. So don’t be afraid of ideal best practices getting rejected by your team because they might just not fit.

Swizec Teller 00:22:58 Then the next level of these best practices being codified is after the cultural level, they can start turning into like little frameworks or libraries. It’s a good way to codify best practices, being like, Hey, you know, I’m noticing that everyone on the team keeps solving the same problem and keeps solving it in roughly the same way. There’s small differences, which make it really annoying to debug in different places, because it looks like the same thing, but it’s not actually the same thing. So what you can do is make a framework out of it or make a small library for your team to use. This is also where a lot of public Open-Source libraries come out of. If somebody noticed a pattern, saw that it’s really useful in many situations and try to codify it in code so that others on the team don’t have to keep solving the same problem.

Swizec Teller 00:23:50 This is like an example from the front-end space is why we have so many form state management libraries is because it’s really hard to get the right layer of abstraction for a form state. But at the same time, nobody wants to build state management for a form the bazillionth time, because it’s always pretty much the same. And it’s really annoying. It’s easy to get wrong in subtle ways. So it’s much better if you pick up a library or like a lot of people, they make a library. Another good example of this is on the front end, when you’re building UI components, you notice that designers reuse a lot of these components in different places, and they have basically zero differences between them because they’re following a design system. If you codify that design system in a UI library, that’s specific for your company and specific for your design system, you then free your engineers from thinking about those details every time.

Swizec Teller 00:24:52 So instead of thinking about pixel perfect positioning of every element on the page, they can just reuse existing components and focus on the business logic and like the user flows instead of the little details. And that speeds up the entire team, which again goes back to our force multiplier stuff we talked about earlier. You notice a pattern, you codify the pattern in some sort of framework or a set of functions and then show it to others. And if it’s working for them, if it’s actually solving their problems, they’re going to start using it and be able to move faster. And then as it spreads to the company, you’ll quickly notice that the entire company is following the same patterns and has those codified best practices,

Brijesh Ammanath 00:25:39 Quite a interesting thought over there. The one which struck me was that a best practice itself is contextual? What might be a best practice in one organization might not work as a best practice in another, with a different context. We will now move on from learning and touch on another important skill or senior engineer needs to have leadership. Any thoughts on how to lead a project, even if you are not managing the people working on the project?

Swizec Teller 00:26:07 Yes. So I think this is probably my favorite part of engineering is the leadership part. Like it’s something that a lot of companies don’t really understand. Some companies understand it more than others, but you see a lot of this equating of leadership and management. But I think that at least in a lot of modern companies that has split, it’s been a trend in Silicon valley for the last 10 to maybe 10-20 years. And it’s kind of spreading to the rest of the tech industry in general, where you can be an engineering leader and you can lead projects, but you’re not actually the direct manager of any of the team. And I think that at least for me, because I’m very technically minded, that’s more interesting. I never want to be never is a strong word. Maybe I’ll change my mind at some point, but I’ve never wanted to be a, like a manager manager, somebody who has to do people management, but I do like to lead projects and I like to have influence on the team around me and have like technical leadership versus people leadership.

Swizec Teller 00:27:19 And what I mean by that is that, the main difference really is on whether you are in charge of the technical direction of a project, or whether you are in charge of the whole career development and coaching and people problems. People managers are more focused on their people’s careers and removing obstacles and like some communication across teams and also like doing the one-on-ones and that sort of thing. Whereas technical leadership is more about, okay, we got a project that is way bigger than a single person can achieve. It might even be bigger than we can achieve in a single sprint. Something that we’re going to be working on over an entire quarter. And there’s going to be three teams working on it, a couple of different PMs. We’re going to be dealing with external vendors and you need somebody who, is kind of at the center of all this, or adjacent to the center who can keep a coherent technical vision for the project.

Swizec Teller 00:28:24 Because what happens a lot is if there’s no responsible person for the technical direction of a project, you end up with a kind of mish mash of approaches that evolve very organically. And there’s no, I’m trying to come up with an example, but it’s hard to think of something that’s going to make sense to everyone who’s listening. But if you’ve ever experienced a project that doesn’t have direction, a good symptom of that might be whackamole bugs, where every time you fix a bug five other bugs show up, or when you are working on some part of the project, and then you realize somebody on the other team, or even on your own team is working, is solving the exact same problem just in a different way, in a different place. And because you didn’t have that oversight together, you didn’t realize that you’re working on the same thing.

Swizec Teller 00:29:15 Or another thing that happens is you get too many cooks in the kitchen where everyone is trying to solve the problem in its own way. And the architecture evolves in strange directions that don’t fit together, or, yeah, so basically it’s kind of hard to put into words, but when you’re in a project like that, it’s kind of obvious that it’s a mess and that nobody has a long term vision for what they’re doing. You’re just focused on your current immediate task. And it’s hard to feel a coherent vision. So that’s where a technical leader or a senior engineer can come in and kind of be like, okay, we need to solve this problem. Our long term vision goes in this direction. This is like what we’re building towards for an entire quarter. And you can explain that to everyone, kind of keep them in the same direction and then help them slice it up for their immediate task.

Swizec Teller 00:30:11 The way you can often do that leadership, is back to what I was talking about earlier, where you’re giving them a code review for example, and you’re giving them feedback and you kind of nudge them and push them in the direction of the overall vision. So you say, Hey, we should do this part that you coded is great. It solves the immediate thing that you were working on, but I think we should do it this other way, because next sprint we’re solving this other thing that’s similar to this, or because in a quarter we’re going in this direction where we need to anticipate future needs. Not to the extent of completely subduing everything to our future needs because that usually doesn’t work, but more like, you know, let’s just move slowly in that direction. So it’s kind of, I think the way I would summarize that is that you can do a lot of technical leadership by just nudging people in the right direction.

Swizec Teller 00:31:10 So set a vision in your mind, hopefully align that vision with everyone else on the team, because it’s much easier to nudge them in a direction if they agree with you and then kind of nudge and kind of, it’s kind of like cat herding to an extent, but kind of just with nudging and gardening. And you’re like, you know, let’s go in that direction. Let’s do a little snip here. I think the gardening analogy probably works best. It’s like when a gardener is trying to make a bonsai tree, or like a nice beautiful tree in a park, the tree grows wherever it wants to grow. What the gardener is doing is cutting and tying and kind of sniping and nudging and coaxing the tree in the direction and shape that they want. It’s very similar with technical leadership. People are doing organically, they’re making changes and you can kind of push them and nudge them in a direction that makes a coherent sense across everything.

Brijesh Ammanath 00:32:08 All right. So if I understood that, right, the technical leader provides that overarching, oversight and leadership and aligns the architecture to the business vision and gets their technical team closer and makes them understand how that tasks align to that vision.

Swizec Teller 00:32:29 Yep, exactly. And then if we want to go more tactical with that, the approach that has worked best for me is doing swarm design sessions at the beginning of every story. So any story that’s a little bigger than just banging it out in an hour or two, you kind of get together on a swarm. You get everyone helping design the solution. And because everyone is designing the solution together, you get a more coherent solution because everyone was in the room when it was being designed, everyone understands the solution that they’re building because they helped come up with it. They feel more aligned because again, they’ve given their input, they’ve explained what they want, they’ve explained their concerns. And you, as the leader also get to hear everyone’s concerns. And then you can kind of nudge them towards the desired solution by asking the right questions or by proposing the right solution. So like somebody suggests a solution that’s going to work, but doesn’t take into account something that you are keeping in your head as the overall vision you can say, Hey, how about this other thing? Or have you thought about this task or feature that we’re going to have to solve next week? And then you can kind of nudge and shape things in a direction.

Brijesh Ammanath 00:33:46 An important leadership skill is influencing. And you touched on this in the answer to the question of leading a project, though, you might not be line managing the team members. I want to dig a bit deeper into influencing because I believe this is a very important skill set for senior engineers. How do you go about influencing other team members or teams to use your solution instead of writing their own?

Swizec Teller 00:34:10 I think influence is, it can be really difficult actually to have influence because people are, you know, people are their own people. I think many engineers don’t actually like to feel influenced. So it’s a lot like trying to find a good way to phrase this. That doesn’t sound bad, but a lot of really experienced leaders that I’ve talked to have said, yeah, you know, managing engineers or leading engineers is a lot like dealing with kids. They all think they know best. And they’re all very temperamental and they just want to do what they want to do, but you have to kind of nudge them in the right direction. So like a funny example from that I’ve heard that works with raising kids, instead of asking them, Hey, do you want to put your coat on? So we can go outside? You say, Hey, do you want to put on the black coat or the red coat when we go outside?

Swizec Teller 00:35:02 And the kids like, oh yes, I love the red coat. And they don’t even realize that not wearing a coat is also an option because that wasn’t an option that was presented to them. That’s a little of a, kind of a manipulative trick, but it really does work. I’ve seen this, it works on me. I’ve seen it work on everyone that I’ve ever tried it on. It’s you present a choice and people can make their own choice, but it’s among the options that work for you. Like a really good example of where this works is organizing meetings. When you, instead of saying, Hey, when do you want to meet? Or, Hey, do you want to meet about this? You can say, Hey, do you want to talk about this at 3:00 PM or at 4:00 PM? And people are like, oh yeah, let’s talk about it at 4:00 PM. Don’t even realize that you are kind of shoving them towards a specific answer.

Swizec Teller 00:35:53 And you can do a lot of that when you are helping design solutions. But I think the main part of influence really is ensuring that people feel empowered and making sure that it is their decision to do what you would like them to do. You’re not going to win every time. And that’s like, you know, just even thinking about it as winning is bad, but usually what works with influencing engineers is making sure that everyone feels like their inputs have been heard, making sure that their concerns have been heard, making time for everyone to raise their concerns with a solution, making time for everyone to propose their solutions and kind of guiding them towards making the decision that you think is the right decision. Part of that is also that it could be that you were wrong. And what you think is the right solution is the wrong solution. So by giving everyone that opportunity to raise concerns, they might also change your mind and you come up with a better result, a better solution in the end.

Brijesh Ammanath 00:36:53 The example of meeting reminds me about a question I meant to ask you. In the timeboxing technique, you recommend scheduling meetings back to back and say that there is nothing worse than a 15 minute break between two meetings. I see two issues here. First health, how do you ensure you do not end up sitting for too long? Secondly, don’t you need the breathing space between meetings to reflect on what was discussed, take notes, et cetera.

Swizec Teller 00:37:21 I think this is from my Programmers Work at Night book. The idea of time boxing is to create a time for a certain task. So like this comes from, I think it’s like behavior change science that talks about, if you really want to get something done, you shouldn’t just say, I’m going to get this done. You have to say, I’m going to get it done at this time on this day. And I’m going to get started by doing X. So what timeboxing helps with is making sure that when you get into flow or when you really fall into it, you also have a stopping point because you can’t think straight for a very long time. So there’s a couple of things that go into time boxing. The one side of the issue is that you’re giving yourself a time limit, because that gives you a little bit of oomph because you have a deadline.

Swizec Teller 00:38:15 You say, I want to finish this in an hour. It also gives you a stopping point because it’s very easy to get stuck in a problem. And like, you know, you’re working on a bug and you’re just banging your head against the wall. And because there’s nothing stopping you, you keep banging your head against the wall. Whereas it turns out that if you step away, go for a walk for 10 minutes, come back. Suddenly it’s much easier to solve. The other thing is context switching is very expensive mentally. So working on a million things at the same time or switching every 10 minutes can be very taxing on focus and on actually making progress on anything. And that’s where timeboxing comes in. If you put similar tasks together, you can kind of get them out of the way. And then you have more time later in the day or before those tasks to focus and do deep work.

Swizec Teller 00:39:05 There’s a lot of literature about this out there. There’s, Deep Work by Cal Newport Atomic Habits by James Clear are both really good books. If you want to go to more underlying sources, BJ Fogg talks about this a lot. He has a whole course at Stanford and he does academic research in this area. But anyway, the thing with meetings and with taking notes between meetings is that as a senior engineer, the more that you have a team around you, it’s almost like you become a decision machine. Youíre less and less expected to do the deep work yourself rather than unblocking others and making decisions. So you can see this a lot in how CEOs behave or how business leaders behave. It’s very similar for senior engineers, especially the bigger the team around you, where coming together with a team talking for 10 minutes or 15 minutes, getting everyone’s input and then be taking a bet and making a decision based on your experience based on where the team is at, based on what you think and being like, okay, so I’ve heard everyone’s input.

Swizec Teller 00:40:11 Let’s go with Option A and that’s it. That’s all that everyone, anyone needed from you. It was that decision because either they weren’t sure enough of themselves to make it, or they need somebody like you, who has a bigger stance at the company. Somebody to take the heat, when the decision goes wrong and decisions often go wrong. And it’s important to be the kind of person who can say, okay, I think Option A has a 60% of chance of working, Option B has a 40% chance of working. Let’s go with Option A and if I’m wrong, I’m going to be the one who stands in front of our boss or the product owner or whoever, and explains we made a decision. This is why it was the right decision at the time. It didn’t work out. Here’s how we’re going to fix it. And in terms of taking notes or taking breaks between those meetings, a lot of that can actually be outsourced.

Swizec Teller 00:41:01 A good meeting that’s well-run means that you don’t have to do a lot of pre-reading. You don’t have to do a lot of pre-work because you can use the meeting itself to get the relevant information, because again, you know what, you need to make a decision. So asking those questions of the people on the call is a lot more effective than them trying to predict what you’re going to ask and giving you all the info in advance. So that can work faster. And then for notes, you can give that to somebody else. That again comes back to the leadership and influence part. You can empower people to take their own notes, to make their own subtasks or to slice up the ticket. And that way you are free to spend more time on that critical piece that only you can do, which is making decisions based on your experience using the neural network in your head, that you’ve trained over a long career to make those decisions much quicker, because you’ve seen how they play out in the past.

Brijesh Ammanath 00:41:59 Right. So by time boxing, you were indicating more of grouping the similar tasks together and so to reduce the context switching rather than discouraging, taking breaks in between and not, negatively impacting your health.

Swizec Teller 00:42:16 Yeah. And like one thing, I actually do a lot and I really like this about my current company, because everyone does this. We put lunches and breaks and walking the dogs and stuff like that on our calendars. So other people know not to schedule meetings over that.

Brijesh Ammanath 00:42:31 Any good tools for time boxing?

Swizec Teller 00:42:34 Honestly, out of all of the tools I’ve tried, the one that ends up working best is just my calendar. So what I’ve been trying to do a lot is just every week or every day kind of look at what I need to do or what I want to get done and just put it on the calendar and say, I’m going to be working on this for half an hour or an hour at this time. It’s not perfect because you then have to also, you have to be in the mental space to do that. But I think with some practice you can get there or you can shift things around.

Brijesh Ammanath 00:43:07 I would now like to ask a few questions about mentorship, how important is it to have a mentor?

Swizec Teller 00:43:14 Yeah. I think mentors are, they’re super helpful. You can always go through life without mentors. There’s also like mentors are like a force multiplier on yourself. Same with coaching. It’s like you can, as a smart engineer, talented, motivated, you can always figure things out on your own, but it’s a lot easier if you can ask someone and they say, oh yeah, you know, I’ve done this 50 million times in my career. Here’s how you do it. Or here’s how I would think about it. That’s super helpful. Getting official mentors can be really hard. It’s easy within a company where, especially for junior engineers, companies often assign mentors for more senior engineers. You kind of have to find someone in the company or around that resonates with you. And then, you know, just take them out for coffee every week or every other week. And kind of talk about things.

Swizec Teller 00:44:12 The main thing about mentorship is that it’s very mentee driven. So nobody is going to sit around and wait to give you advice. It’s more like you have to go out and talk to them and explain your situation and like not exactly pull things out of them, but find somebody who’s willing to talk to you and listen to you and share ideas and just ask them questions and see whatever you’re struggling with, whatever you’re dealing with. Just ask them, get help. Like the most basic example of mentorship in tech companies are code reviews for more like career mentorship. Often your manager does that. Although in bigger companies that can get a little tricky because of misaligned incentives, just making friends in the industry is super helpful where you can be like find somebody who’s more experienced and just talk to them, you know, enjoy their company, have kind of an unofficial mentorship going on.

Swizec Teller 00:45:07 Like there’s a lot of people thinking back on my career that were my mentors and neither of us probably realized that they were my mentors at the time were just, oh yeah, I actually ended up getting a lot of really good advice from this person. And I now consider them my mentor. Another approach is kind of like mastermind groups. This is more like peer mentoring, where you find a group of people who are going through similar life phase, similar career phase, similar technical challenges as you, and just set up a call with them once a week or grab a beer once a week and just talk about what you’re doing, what you’re going through and kind of mentor each other in real time. That’s also a really good practice for mentoring others in a more formal position

Brijesh Ammanath 00:45:52 As a senior engineer, it’s your responsibility to ensure that you have a high performing team. So I wanted to ask some questions about performance management. What factors should one consider while managing the performance of senior engineers?

Swizec Teller 00:46:08 I think the best analogy for managing the performance of senior engineers comes from like the shipping industry, where there was a famous example online where I think it was UPS or something like that was paying workers per hour. And by workers I mean here, delivery drivers who are like, who are in a van with a bunch of packages in the trunk and they have to deliver them. If you pay them by the hour, it turns out all of the deliveries were late all the time. Everything was always late because people were incentivized to work as slow as possible. You know, if I work 10 hours, I’m going to get paid more than if I get it done in six hours. But then the company switched to paying per I think per package delivered or per van emptied, something like that. And as soon as they started paying per package delivered, delivery rates doubled, I think the amount of time drivers spent was like half or even less than that because it’s like, okay, well I’m getting paid, let’s say a hundred dollars to deliver 50 packages.

Swizec Teller 00:47:11 I can either get that done in three hours or in six hours. Obviously they’re going to want to do it in three hours. So it’s very similar with engineers where if we are valued for delivering features or delivering business value, we’re going to naturally approach our work much differently than if we’re incentivized for button seats time. And like button seat is probably the worst possible way to manage the performance of a team. It usually shows that the manager in question or the business in question doesn’t really trust their engineers to be hardworking. People doesn’t trust their engineers to do the work. And that’s why like a lot of bad managers manage by making sure if you’re available from 10-6 or 9-5 or whatever, then I’m sure you are at least working. I might not know if the work is getting done. I might not care, but at least I know you’re there and you’re trying.

Swizec Teller 00:48:05 So that’s what I care about. And usually those companies are very slow at shipping. They fall behind with the competition, whereas companies who focus on deliverables where it’s like, we don’t care how long this takes. We don’t care how you do it even to an extent, we have this OKR, objective and key result, we have this business metric that we want to hit. Go figure it out, have fun, make sure that I donít know sales are up by 10% by the end of the quarter and or like just increase sales by 10% and the faster you do it, the better. People approach that situation a lot differently. They naturally are more incentivized to work harder to find more of those quick solutions and kind of hacks like we talked about earlier, where actually, I’m not sure if we talked about that, but they just end up shipping faster and being more focused on the actual results rather than pontificating and having long debates about what is the perfect way to write something. Because the business usually doesn’t really care about the perfect way to code something.

Swizec Teller 00:49:08 They care about the business result. So if you also incentivize engineers based on business results, and if you manage them based on business results, everything else tends to kind of fall in line with that. So that’s what I’ve seen work best. And we do this at my current company and I think everyone that has joined from product owners to engineers, like there’s this moment after two or three weeks or maybe a month. And they’re like, I have never seen a team move this fast before. Like I’ve never worked at a team that’s able to deliver projects so fast and so accurately. And it’s all because we are managed and we manage ourselves based on business deliverables, based on achieving results rather than on doing the work

Brijesh Ammanath 00:49:53 In summary, make outcomes, the primary metric for performance management. Is that right?

Swizec Teller 00:49:59 Yeah. Based on outcomes instead of inputs.

Brijesh Ammanath 00:50:02 The last section is questions on growth and career progression. What training should a company ideally provide to senior engineers? Are there any companies that are doing a good job on this?

Swizec Teller 00:50:16 I think there’s a lot of companies out there that kind of struggle with figuring out what to do with very senior engineers. The main thing is that, you know, one thing I’ve noticed in my career is that once you get that senior engineer title, it’s like a senior engineer could be anyone between five years of experience and 30 years of experience, they’re all senior engineers. So it kind of feels like your career almost like ends at that point when you become senior. But I think what’s hiding underneath there is yes, a lot of people go into management, but if you ask me that’s a different career, you don’t actually get promoted into management. You’re changing careers and you can go from management back to coding and back to being an engineer, but it is a different career. It’s a different skill set. It’s a different path.

Swizec Teller 00:51:03 But if you want to stay engineer, you can keep growing on the engineering track, which to be honest, often looks like it goes outside the company because yes, there’s principal engineers. And I think there’s Microsoft or somebody has distinguished fellows and stuff like that, where it’s almost like being a tenured professor and you can basically do whatever you want from what I’ve heard. There’s very few of those. There’s a lot more managers than there are distinguished fellows at these companies. It’s going to be very hard to get there. What you can do instead and what you can focus on instead is finding ways to solve bigger and better problems. So companies often don’t have any new challenges to offer senior engineers because the company itself isn’t really growing, isn’t getting that much better. So there’s nowhere for senior engineers to go. What you can do in that case rather than what often happens is you get bogged down into being an architecture astronaut.

Swizec Teller 00:52:04 And so making perfect solutions, you can change companies to go into a company that does have those bigger, better problems. Because you know, a senior engineer at a five person startup is a very, very different job than a senior engineer at a thousand engineer company. And also your growth is very different that like if your company is growing from like, I’m going to make up some numbers, but let’s use employees as a proxy for everything else. If your company is growing from 10 employees to 15 employees in two years, that’s going to be a much different experience than if you’re growing from, let’s say 20 employees to 300 employees in a year. You’re going to learn a lot more at the company that’s growing faster and the challenges that you’re solving and the things that you get to see are going to become interesting a lot faster. And you can stay a senior engineer at the company that’s growing like that for a very, very long time because they just keep having new and more interesting challenges. Or you can switch to a bigger company and get new, more interesting, bigger challenges that way, that kind of force you to think differently and go bigger.

Brijesh Ammanath 00:53:18 What skills would you focus on as a junior engineer to become a true senior engineer?

Swizec Teller 00:53:23 So I think most junior engineers here, I mean true real junior engineers who don’t have a lot of experience in actually delivering coding and results, I would focus primarily on getting better technically? Focus on the technical skills so that later when you are a senior or even when you’re a mid-level, you decoding is not holding you back. It’s almost like a second thought is how to deliver the result versus designing the result. Then as you become a made and a senior start shifting more towards focusing on how to solve the problem and how to design a solution rather than the actual implementation. And then also start adding those leadership skills and solving bigger problems. And one thing that everyone can learn and that everyone can work on is the ownership mentality. This is something I talk a lot about in my newsletter as well is really owning the thing that you’ve been tasked with solving.

Swizec Teller 00:54:25 It’s like, Hey, even as a junior, when you get a subtask or like a small part of the overall problem really own that, figure out all the ways you can make it better, write all the tests, like be proactive, own the result, own the outcome, understand how it adds up to the overall picture, but really like don’t code something up and throw it over the fence. And eh, it’s fine enough. It’s more like code something up, really think about how you can make it better. Think about how you can write tests that prove that it’s correct. Think about how you can test it yourself then like, you know, I need to work on better examples for the ownership stuff. But the idea is that you take responsibility for the result of whatever piece of the puzzle you’ve been tasked with. And re-own that part and kind of project manager yourself own it, focus on delivering the result rather than just doing something others told you to do. And then moving on.

Brijesh Ammanath 00:55:23 What advice would you have for junior engineers? Is it better to join a big or a small company?

Swizec Teller 00:55:31 I think that really depends on what kind of person you are or maybe not what kind of person you are, but what interests you. If you go into a smaller company, you’re going to get a lot more ownership, a lot more responsibility, a lot faster. It’s almost like being thrown in the deep end. Like I started my career as the only programmer in the entire company. And that was great. It really forced me to learn a lot really, really quickly, but it also meant that I was doing weird things that don’t make sense to anyone who’s ever worked in a professional environment before I was building solutions that I probably didn’t need to build because if I had someone like a mentor or a more experienced peer, they could be like, Swizec, that is stupid. Just use the library. I know you don’t know about the library, but you don’t have to build everything from scratch yourself.

Swizec Teller 00:56:22 But I did because I just didn’t know about these things, right? Whereas at the bigger company, you get a much more streamlined experience. You get to see how big companies work. You get a lot of support from everyone around you. You get people mentoring you. If you run into any issues, you can just go ask somebody, some of your peers, you get it’s a lot more like being thrown in the shallow end of the pool with five lifeguards around you who are helping you and making sure that you’re going to learn how to swim properly. So I think both can work personally. I like being thrown in the deep end and figuring things out, but it does mean that later when I get better advice or when I learn better things, I have to unlearn a lot of bad practices. Whereas somebody who starts the big company learns a lot of good practices by default, but then might also struggle with growing much slower, having a slower career path. And then if they do ever transition to smaller companies because they want more of that ownership or they want more responsibility, it can be hard to adapt,large company thinking to a smaller company where you have to move faster and be more willing to experiment and do weird things.

Brijesh Ammanath 00:57:35 So in summary it, the job there are pros and cons to each and make the best of the opportunity.

Swizec Teller 00:57:41 Yes. Yeah, exactly.

Brijesh Ammanath 00:57:42 Finally, I would like to conclude our session with a couple of questions that are quite generic. Industry trends, what resources do you use to stay up to date?

Swizec Teller 00:57:52 It’s really bad, but I’ve been using Twitter for a really long time because I feel if you follow the right people on Twitter, it’s like, yes, you see a lot of weird politics and stupid stuff, but you also see a lot of early ideas and early trends. Like there’s been a lot of examples where I saw somebody tweeting about an experiment or thinking about doing something. And then later three months later, or six months later, it became a really big seminal talk at the major conference that shifted the entire field in that direction. So that’s a really good way to keep up with the future trends are going to be like, but that’s a lot of work and that can be hard. And there’s a lot of noise keeping up with trends that are already here is easier through like books. When you start seeing a lot of books being published about the topic, that’s usually a little late into the trend or later because books usually take two or three years of research before somebody publishes. So you are a little more behind, but you get to see things that have survived the test of time, things that are actually going to be the trends for the next 10, 20 years, rather than for the next six months. Newsletters are also great. And I think kind of what works for me is kind of just keeping an eye out, looking at hacker news, sometimes looking at Reddit, Twitter, seeing what books people are talking about and then kind of following trends that way.

Brijesh Ammanath 00:59:19 You were writing a book titled Why Programmers Work at Night? Do senior programmers also work at night?

Swizec Teller 00:59:27 Honestly, I think yes and no. The main trust of that book was that people work at night, but the nighttime can actually be early in the morning. And it’s more about finding focus to work on your own things. I think a lot has changed in the industry since I first published that book or rather in the industry has professionalized a lot. So people rather than working at night, it’s a lot more, you know what we want work life balance. We are professionals. We, especially the corporate programmers, they have a lot more of a professional attitude towards all this, right? It’s like I come in at 9:00 AM or whatever works for me. And I finish when I finish because I have a life outside of this. I have kids to take care of. I have family, you know, I don’t want to spend my entire life programming. Whereas the younger folks or the people who have like indie hackers or people who have site hustles, there’s a lot of working at night or working on the weekends just because you like it.

Swizec Teller 01:00:25 And honestly, if you look at Open-Source, I think a lot of that does still happen at night, especially for people who aren’t doing it full time. It’s like you either wake up early and you get two or three hours of coding on your favorite Open-Source project or pet idea before you start with the meetings and the boring stuff. And like, oh yes, I managed to write five lines of code at work today. It’s like, I just spent two hours in flow working on some really interesting problem that really pulled me in. And I almost forgot to go to work, very different modes, right?

Brijesh Ammanath 01:00:58 Agreed. Before we conclude the catchall question, was there anything I missed that you’d like to mention?

Swizec Teller 01:01:06 I think I’d love to mention that a lot of the Senior Mindset stuff that we’ve been talking about is on and it became an ebook as well that people are really enjoying. And it’s kind of a combination between how to be a true senior engineer, how to think that stuff and also different career paths and approaches to how to leverage the actual senior engineering stuff to having a better life outside of engineering. Cause you know, it turns out that we don’t have to think about code and technical stuff all the time. There’s a lot of other things out there.

Brijesh Ammanath 01:01:40 I’ll make sure I link to that in the show notes. People can follow you on Twitter, but how else can people get in touch?

Swizec Teller 01:01:47 Yeah. So I’m @Swizec on Twitter. I have a blog on that has a newsletter and I try to be really good with replying to everyone who writes me an email or replies to one of my things. I don’t always get to it on right away, but I try to get there eventually.

Brijesh Ammanath 01:02:06 Swizec, thank you for coming on the show. It’s been a real pleasure.

Swizec Teller 01:02:15 Yeah. Thank you for having me. This was great.

Brijesh Ammanath This is Brijesh Ammanath for Software Engineering Radio. Thank you for listening.

[End of Audio]

SE Radio theme: “Broken Reality” by Kevin MacLeod ( — Licensed under Creative Commons: By Attribution 3.0)

Join the discussion
1 comment

More from this show