Vox

Leitura de 37 min

Swizec Teller and the Senior Engineering Mindset, Part Two

Summary

In this second part of the conversation with Swizec Teller, the discussion delves deeper into the practical aspects of the senior engineering mindset. The focus shifts from technical prowess to the softer skills that differentiate true senior engineers: prioritization, delegation, and creating environments where others can thrive.

A key theme is the shift from being an individual contributor who implements solutions to becoming a force multiplier who enables the team. This involves holding back from solving problems directly to let others own them, asking guiding questions, and reviewing work to build robust solutions collectively. The senior engineer’s role is framed as shaping the environment and platform so that the entire team becomes more productive and empowered.

Another major topic is the path to promotion and gaining more responsibility. The misconception that becoming more senior requires learning new languages or frameworks is debunked. Instead, advancement comes from aligning with business value, taking ownership of bigger projects, and demonstrating reliability. Leadership delegates responsibility, not tasks, and an engineer’s capacity to handle that responsibility—including owning failures—is highly correlated with career growth.

The conversation concludes with advice on probabilistic thinking, inspired by books like Thinking in Bets. Senior engineers make decisions based on expected value and are comfortable making bets, understanding that a good outcome doesn’t necessarily mean a good decision, and vice versa. This statistical approach allows them to unblock teams and make faster, more confident decisions.

Recommendations

Books

  • Thinking in Bets — By Annie Duke. Swizec found this book impactful for learning to make decisions based on probabilities and expected value, understanding that a good outcome doesn’t guarantee a good decision and vice versa.
  • How to Win Friends and Influence People — Recommended by Swizec as one of two books that will have a bigger impact on an engineering career than technical books, focusing on interpersonal skills.
  • The Goal — By Eliyahu Goldratt. Swizec says this book on the theory of constraints in manufacturing shaped his ideas about the true goal of engineering being to achieve business objectives, not just writing code.
  • The Phoenix Project & The Unicorn Project — Described as spiritual successors to The Goal, applying the theory of constraints specifically to software engineering and IT systems, and forming the basis of the DevOps movement.

Tools

  • LaunchDarkly — Featured as the episode’s sponsor. A feature management platform that allows teams to deploy code safely using feature flags, test in production, and release features incrementally without redeploying.

Websites

  • seniormindset.com — Swizec’s website where he offers a series of essays/emails on the senior engineering mindset, compiled into an ebook. It’s a collection of his most impactful writings on the topic.
  • swizec.com — Swizec’s personal blog, which he describes as containing a mix of more off-topic, technical, and mindset-related content.

Topic Timeline

  • 00:00:00 — Introduction and recap of Part One — The host introduces the episode as a continuation of the discussion with Swizec Teller on what differentiates senior engineers. They recap that part one began exploring the mindset shift from a non-senior to a senior engineer, beyond just having the title.
  • 00:01:08 — System design over algorithms for senior impact — Swizec discusses how senior engineers find the biggest opportunities in system design, not algorithmic optimization. He gives an example of engineers obsessing over a micro-optimization on an array of a thousand elements while ignoring the half-second cost of three API calls. In modern web development, compute is cheap, and bottlenecks are often elsewhere.
  • 00:03:12 — Prioritization as a critical senior skill — The conversation highlights prioritization as a key skill where many engineers fail in interviews. Swizec describes a refactoring interview exercise designed to be impossible to complete, meant to reveal how a candidate prioritizes tasks. The host adds that in take-home exercises, they look for a clear written rationale behind prioritization decisions, which indicates a coherent engineering philosophy.
  • 00:07:04 — Mentoring through explainable decisions and avoiding bottlenecks — They discuss how having a clear, explainable decision-making process is crucial for mentoring. A senior who can explain the ‘why’ behind decisions empowers the team to make similar decisions independently. This prevents the senior from becoming a bottleneck and a single point of failure, allowing the team to function even in their absence.
  • 00:08:27 — Senior engineers hold back to empower the team — Swizec observes that staff-level and senior engineers often hold back from immediately solving problems. Their role is to shape an environment where anyone on the team can own important problems, moving away from the ‘10x developer’ myth. The host shares his practice of owning a story but only contributing through PR reviews and questions, guiding the team to the solution themselves.
  • 00:11:44 — Common misconceptions about becoming a senior engineer — Addressing a listener question, Swizec identifies the biggest misconception: thinking you need to become more technical or learn new languages/frameworks. The real shift is towards problem-solving and business alignment. Advancement comes from taking responsibility for bigger projects, showing results that impact business metrics, and earning trust from leadership to lead critical initiatives.
  • 00:22:39 — Autonomy comes from responsibility, not task specification — They explore how true autonomy in engineering is correlated with the capacity to take responsibility for outcomes, not just the freedom to implement a spec. Most engineers want autonomy but aren’t ready for the weight of responsibility that includes potential failure. Leadership delegates responsibility, and handling that—especially when things go wrong—is what leads to more autonomy and promotion.
  • 00:25:45 — Learning from failure and psychological safety — The discussion turns to how cultures that support learning from failure are essential for growth. The host advises job-seekers to ask what happens when things go wrong. A healthy culture expects you to learn, apply those lessons, and have a response plan, rather than fostering blame. Owning a situation when ‘shit hits the fan’ is where real ownership is demonstrated.
  • 00:29:33 — Thinking in bets and probabilities for decision-making — In response to what he wishes people asked him about, Swizec advocates for thinking in probabilities and making bets, inspired by Annie Duke’s Thinking in Bets. This involves evaluating options based on expected value, making a confident decision, and being comfortable that a bad outcome doesn’t mean a bad decision. This mindset allows him to parachute into meetings and unblock teams by making decisive calls.
  • 00:37:16 — Final advice: Key books for career impact — For his final piece of advice to engineers of all levels, Swizec recommends two books: How to Win Friends and Influence People and The Goal by Eliyahu Goldratt (on the theory of constraints). He states these will have a bigger career impact than technical books, as they focus on the real goals of engineering and business. He also mentions their spiritual successors for software: The Phoenix Project and The Unicorn Project.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2022-03-23T07:00:00Z
  • Duration: 00:40:48

References

Podcast Info

Transcript

[00:00:00] In today’s episode, we pick back up with our guest, Sozek Teller.

[00:00:08] In the first part of our discussion, we began the conversation on what the differentiators

[00:00:13] are between a senior engineer and a non-senior engineer.

[00:00:17] You may think that you’re a senior engineer based on your title, but in these two episodes,

[00:00:22] we’ll talk about that mindset shift.

[00:00:25] So has also created seniormindset.com.

[00:00:27] We’ll talk a little bit about that in today’s episode as well.

[00:00:30] Thanks so much for listening to Developer Tea.

[00:00:32] Let’s get straight into our discussion.

[00:00:34] This was Sozek Teller.

[00:00:36] So, but the other, yeah, this is incredible.

[00:00:42] Oh, I was just going to say this.

[00:00:44] It’s incredible how these fundamental things, you know, I think when I was a younger engineer,

[00:00:50] I thought, okay, the hard part is in the algorithms or the hard part is, you know, in some kind

[00:00:57] of design specific, you know, the specifics of the way that I’m dealing with this stuff,

[00:01:02] the data stuff is all easy.

[00:01:03] We just throw it in there and then fetch it out.

[00:01:06] But all of the other things are the hard part.

[00:01:08] But amazingly, the system design problems tend to be where the biggest kind of opportunities

[00:01:17] are for seniors.

[00:01:19] Yeah, because especially with modern computers, algorithms just aren’t that important anymore

[00:01:26] because compute is very, very cheap.

[00:01:29] And at least in web programming, we use languages that are so slow that it gets overshadowed

[00:01:38] by the slowness of the web as a platform.

[00:01:42] Like a really cool example I like to use is when people have a function that makes three

[00:01:48] API calls and then it then does some data manipulation or an algorithm with an array

[00:01:55] of a thousand elements and they will spend so much time with all complexity and looking

[00:02:02] at that algorithm for a thousand elements and obsessing over it and figuring out how

[00:02:07] to make it perfect.

[00:02:08] It’s like, yo, you’re spending half a second on making three API calls.

[00:02:12] Yeah.

[00:02:13] Wouldn’t you want to look at that instead?

[00:02:17] It’s going to be much more effective use of your time, right?

[00:02:20] Exactly.

[00:02:21] Yeah.

[00:02:22] Yeah.

[00:02:23] I think about complexity a lot, but I don’t think about it a lot because I’m dealing with

[00:02:29] it in an algorithmic sense.

[00:02:31] I think about it more as a mental model.

[00:02:33] And so for that reason, I’m excited when I hear that people have some kind of formal

[00:02:40] understanding of that because we can have that common language.

[00:02:43] How rarely is it because the code that we’re writing is, you know, we need to go from linear

[00:02:50] to log or whatever.

[00:02:52] That’s not the point of that particular skill.

[00:02:56] It’s more of a thinking tool than it is actually practically useful.

[00:03:01] Totally.

[00:03:02] Yeah.

[00:03:03] And it’s good to at least think about so you don’t have accidental complexity or super

[00:03:11] algorithms.

[00:03:12] But I think the other important skill for a senior is prioritization.

[00:03:20] And that’s something we see a lot of seniors fail in interviews is because they don’t know

[00:03:26] how to use their time effectively.

[00:03:29] One of my favorite interviews to give is a refactoring exercise that’s specifically designed

[00:03:35] to take too long for an interview if you want to do everything.

[00:03:41] And we tell this to interviewees.

[00:03:44] We say, you don’t have time to do everything.

[00:03:47] Even if you think you do, we promise you that you don’t.

[00:03:50] So we want to see how you prioritize.

[00:03:51] What is it that you go fix first?

[00:03:54] And it’s one of the most, next to system design, I think that’s one of the most revealing

[00:04:03] for whether someone is ready to actually be a senior or if they just have the title.

[00:04:09] One of the things that I look for, especially in senior applications, because most of the

[00:04:16] time we have a small exercise and I haven’t done it in my current role, but I’ve done

[00:04:24] it in previous roles.

[00:04:27] The exercise, what I’m looking for most of the time is exactly what you’re talking about.

[00:04:32] The ability to prioritize.

[00:04:34] We explicitly will provide some kind of small window.

[00:04:40] We do this for a couple of reasons.

[00:04:41] The first one is we genuinely don’t want you to spend a ton of time on this because it’s

[00:04:48] not, the ROI is not there for anybody, right?

[00:04:53] We’re really just trying to assess how you approach problem solving.

[00:04:59] As a secondary part of that, we cap it well under what it would take to actually do everything

[00:05:07] to the degree that feels complete.

[00:05:11] The possible features you could build far extend beyond the time window.

[00:05:17] What we want to see is what do you choose to do first?

[00:05:20] What do you choose to do in the initial parts of this?

[00:05:27] The requirements are very clearly laid out and the nice to haves are very clearly laid

[00:05:34] out.

[00:05:35] Did you put in a nice to have and skip over the requirements?

[00:05:39] That would indicate a problem with prioritization.

[00:05:43] Then also, most of the seniors, and I bet you have something about this in your set

[00:05:51] of opinions about seniors.

[00:05:53] Most of the great developers that we hire, that I’ve hired in the past, will have such

[00:05:58] a clear way of writing what their decision-making process was, but also what they would do next.

[00:06:06] Why did they prioritize this way?

[00:06:09] Why specifically did they cut this out, but put this in?

[00:06:14] That has been a consistent factor in virtually every senior engineer that I’ve ever hired.

[00:06:21] It’s almost like looking for whether they have a consistent philosophy of software engineering.

[00:06:31] If they have an approach that they like to take, even if it’s an approach I don’t agree

[00:06:36] with or that we have disagreements on, it should exist.

[00:06:42] A senior should have seen enough code in their life that they have strong opinions, hopefully

[00:06:47] weakly held, but at least strong opinions.

[00:06:53] The reason that’s important isn’t just because it shows that you have clarity of thought

[00:06:58] and clarity of mind, but it’s super important for the mentoring portion of the senior role,

[00:07:04] because if you’re able to help the rest of your team come to decisions and design things

[00:07:11] and also explain why you made that decision or how you made it, they’re not going to have

[00:07:17] to ask you next time.

[00:07:18] They’re going to be able to make it themselves.

[00:07:20] That’s how you can actually grow the rest of the team around you.

[00:07:23] Otherwise, you end up being one of those seniors that’s just bogged down in messages all day

[00:07:29] every day and they can’t do anything and you become a single point of failure for anything

[00:07:34] getting done on your team, whereas if you can explain every decision, you can be making

[00:07:40] fewer and fewer of them as time goes on and people are empowered to step into those roles.

[00:07:46] Yes, this is absolutely one of the biggest multiplier factors, not only because you don’t

[00:07:54] want to be a bottleneck, but because you may not be there all the time.

[00:07:59] You could be out on vacation, you could go to another team, and it’s a part of the kind

[00:08:08] of life cycle of work for you to be absent, and a great senior engineer knows that their

[00:08:15] absence shouldn’t mean that the team falls apart.

[00:08:19] Another thing I think about with this is when you have a great senior engineer, they don’t

[00:08:27] always rush to be the person who solves the problem.

[00:08:34] I’ve noticed this, especially with staff level, this is like the senior senior engineers.

[00:08:41] They almost hold back from solving the problem because they want to make sure that the atmosphere

[00:08:52] on the team is that anybody can own problems that are happening on the team.

[00:08:58] It doesn’t always have to be, even the important problems, it doesn’t always have to be the

[00:09:02] senior engineers.

[00:09:03] We want everybody to be involved with this.

[00:09:06] I found this very striking because I think as a younger engineer, you think that your

[00:09:12] role as a senior is to be that super-powered 10x developer, whatever that incorrect picture

[00:09:20] is, but really your role is to try to shape a more useful environment almost.

[00:09:32] Environment shaping and platform shaping to the degree that other people can be incredibly

[00:09:38] productive.

[00:09:41] One of my favorite things to do in this area is to…

[00:09:46] On my team, we have the concept of almost distributed ownership where anyone on the

[00:09:52] team can own a story, and that means you own it.

[00:09:55] You actually own the outcome of that story, and you’re responsible for it.

[00:09:59] One of my favorite things to do is to take on that ownership role for a story and not

[00:10:05] actually be involved in any of the implementation directly.

[00:10:08] All I do is review PRs, answer questions, and create an environment where I’m not actually

[00:10:15] creating the solutions.

[00:10:17] My input to the final solution is more in asking questions and being like, okay, so

[00:10:24] you’ve solved this, awesome.

[00:10:26] Have you thought about this edge case or have you thought about that thing?

[00:10:29] What about if this happens?

[00:10:32] Through those questions, helping the team come up with a really great solution that

[00:10:38] then ends up being reliable and robust.

[00:10:41] Because they’ve come up with the solution, they then also have that lesson for next time

[00:10:46] so that they will think about it before somebody asks them.

[00:10:50] Yeah, it is really about creating this portfolio of solutions or models for solutions and then

[00:11:04] taking advantage of that as a team together I think is hugely valuable.

[00:11:10] I’m curious, this is kind of shifting gears just a little bit.

[00:11:15] If I am a junior engineer or maybe I’m right on the verge, maybe I have that title, I have

[00:11:24] that senior title, but really I’m looking to become truly a senior engineer, maybe the

[00:11:30] company that I work for calls it a staff engineer or an architect or something like that.

[00:11:37] What are the most common misconceptions that I might have about what it takes to become

[00:11:44] a senior engineer and how do I fix those?

[00:11:48] I think the most common misconception is that people think they need to become more technical

[00:11:55] or better at technical solutions, learn a new language, learn a new framework or any

[00:12:02] number of those things that everyone on the internet is always telling us we should do.

[00:12:07] Go learn Rust, go learn Haskell or whatever.

[00:12:10] I don’t think any of that will actually have as much of an impact as it would to shift

[00:12:17] your mindset to be more involved with the problem-solving part of it, not the implementation

[00:12:22] part.

[00:12:24] What I said earlier, going from being a better and better hammerer to being really good at

[00:12:31] using a hammer to solve business problems because that’s what fundamentally gets measured

[00:12:38] in companies, is who’s solving the business problems, who is bringing in essentially

[00:12:44] like who’s bringing in the money.

[00:12:49] Lawyers have this concept of bringing in clients and that’s how you get promoted in engineering.

[00:12:55] I think it’s taking on responsibility, not the implementation, but the responsibility

[00:13:01] of bigger and bigger projects being successful.

[00:13:06] As you get more involved with your product managers and talking more to them, that will

[00:13:12] propagate throughout the company and then what I think is really staff and above level

[00:13:18] is when you can own the technical aspect of company-wide initiatives and objectives.

[00:13:32] It’s hard to fully put into words, but I think what happens is that as you start thinking

[00:13:39] more in those ways and being vocal about the business problems and having that hunch for

[00:13:46] what is important to solve and what isn’t important and focusing on the important stuff,

[00:13:52] that gets noticed in the organization and responsibility just starts sticking to you

[00:13:59] like you’re made of glue or something like that.

[00:14:02] As you get more of that responsibility, that’s where those promotions come out of.

[00:14:10] But I’ve never been a manager, so I don’t actually know what it is.

[00:14:14] If that’s true, if that’s what managers look for, but that’s what I’ve noticed managers

[00:14:19] have been pushing me towards and what’s been noticed the most in the organization.

[00:14:26] To give you an example, writing better JavaScript or splitting things into microservices or

[00:14:31] introducing TypeScript, that’s great.

[00:14:33] My manager notices that and he says, this is really awesome, let’s keep going.

[00:14:38] But what gets my head of engineering to come to Slack me and say, yo, we have this really

[00:14:44] important business objective coming up, I want you to lead the implementation of it.

[00:14:49] You have free pass to talk to the VPs of the vendors to choose which vendors want to use,

[00:14:55] anything you need, we want this to happen because it’s critical to the business.

[00:15:00] I think that came out of showing the results and being like, hey, we focused on the important

[00:15:06] stuff, I was leading the project, we shipped it, it shipped on time, it got the results,

[00:15:12] it really had a big impact on business metrics and that’s what gives you that trust from

[00:15:19] leadership to go, we want you specifically to own these projects and to lead these projects

[00:15:24] because we’ve noticed that when you do that, they go better than when somebody else does it.

[00:15:30] Yeah. If you put yourself in the position of a manager or a leader, head of engineering,

[00:15:38] all of those positions have different, I guess, kind of motivations.

[00:15:45] As a manager, I’m looking for your performance over time, I’m looking for how you’re affecting

[00:15:51] the team. As a head of engineering, I might be looking for you to be a key part of a strategic

[00:15:58] initiative. A head of engineering might be less concerned with, let’s say for example,

[00:16:06] you investing in your immediate teammates, whereas your manager is much more concerned with that.

[00:16:13] I think there’s a good balance here. It’s important for the senior mindset engineer

[00:16:21] to recognize that there are going to be, and for what it’s worth, there’s going to be competing

[00:16:27] incentives that are trying to pull you in multiple directions and part of your job

[00:16:34] as a senior engineer is to, once again, to be able to prioritize that, to know when is it the most

[00:16:43] critical thing for me to do to go and be a part of this outside strategic initiative that doesn’t

[00:16:50] necessarily involve my team directly versus when is it time to spend time with my team reviewing

[00:16:57] their code. These feel like very different exercises, both with perfectly good reasoning

[00:17:05] as to why you would choose to do them. Yeah, exactly. A lot of those external

[00:17:11] leading core initiatives comes down to the bushwhacking I was mentioning earlier.

[00:17:16] If you’re there in those early conversations and you have the lay of the land,

[00:17:20] when you get to the super-sliced agile user stories, you are the one who has that

[00:17:29] broad lay of the land and can help guide your team to a solution that’s not going to fall

[00:17:34] apart by the time you get to problem number five because you have that long-term view of it.

[00:17:41] Mm-hmm. Yeah. I hope that we’ve helped some people change the way they think about

[00:17:51] becoming a senior engineer. What does that job look like? Hopefully, we’ve actually helped some

[00:17:58] people feel like it’s more accessible because especially if you thought, well, I have to learn

[00:18:03] six more languages or I’ve got to have these three certifications before I can be a senior.

[00:18:10] In almost every case I’ve ever seen, that’s not true. What is true is exactly what you’ve been

[00:18:18] talking about, which is aligning yourself with that value stream in the business and enabling that

[00:18:26] both through your own contributions and helping others enable that through their contributions.

[00:18:31] I think that is really the key to becoming a senior engineer, not only just becoming a senior

[00:18:37] engineer but actually helping the business succeed. That’s actually how businesses operate

[00:18:45] and it seems kind of foreign in some ways to an engineer to say, well, the code is not really

[00:18:52] necessarily the thing that makes the business operate. Well, that’s actually true and you have

[00:18:58] an opportunity to step into that value stream. That’s how you’re going to grow in your career,

[00:19:04] probably the fastest. We’ll be right back with our discussion with Swizz Teller

[00:19:10] right after we talk about today’s sponsor.

[00:19:29] This episode of Developer T is proudly supported by LaunchDarkly. LaunchDarkly is feature

[00:19:33] management for the modern enterprise, fundamentally changing how you deliver software.

[00:19:38] And here’s how it works. LaunchDarkly enables development and operations teams to deploy code

[00:19:42] at any time, even if a feature isn’t ready to be released to users. Wrapping your code with

[00:19:48] feature flags gives you the safety to test new features and infrastructure in your production

[00:19:53] environments without impacting the wrong end users. When you’re ready to release more widely,

[00:19:58] it’s as simple as updating the flag status and the changes are made instantaneously

[00:20:03] by the real time streaming architecture. You don’t need to waste your time

[00:20:08] building the system that does the feature flags. In fact, that’s pretty hard and error prone.

[00:20:14] Instead, focus on delivering value to your customers. Head over to launchdarkly.com

[00:20:23] and get started today. With LaunchDarkly, you’ll innovate faster, deploy fearlessly,

[00:20:29] and make each release a masterpiece. Thanks again to LaunchDarkly for sponsoring

[00:20:33] today’s episode of Developer T.

[00:20:40] Exactly. It’s like, I think especially at higher leadership levels, the only thing that’s really

[00:20:57] visible is are the business metrics going in the right direction and who is most likely to get them

[00:21:05] to go in the right direction and who just isn’t a problem to work with at a fundamental level.

[00:21:13] It’s like, if we take you, the project is going to get done. It’s going to get done on time

[00:21:20] or at least there’s going to be a very good reason why it’s not done on time,

[00:21:25] but it’s still going to get done eventually. We can just trust you that if we give you a problem,

[00:21:30] it’s just going to get resolved. You’re going to keep us updated on progress. We’re not going to

[00:21:37] have to follow up 10 times to make sure it got done. It’s like when you hire a plumber,

[00:21:42] you want a plumber who comes in and you say, toilet’s broken and they fixed the toilet and

[00:21:48] you don’t even know what happened, but the toilet now works better. Or do you want the plumber who

[00:21:52] comes in and is like, well, what do you want? Do you want me to change that pipe or do you want me

[00:21:57] to close that faucet? I don’t know. You’re the expert. Just fix my toilet. And that’s kind of

[00:22:04] how the higher and higher you go in leadership, that’s more and more how they think about it.

[00:22:09] I don’t know how you do it. Just fix it. Yeah. And if you were to think about

[00:22:20] being in a leadership position and trying to solve a bunch of problems,

[00:22:25] do you want to have to tell each person how they’re going to solve the problem and

[00:22:32] not be able to… It really comes down to delegation of responsibility. It’s not delegation

[00:22:39] of tasks. It’s delegation of responsibility. Exactly. Because whoever is giving you that

[00:22:47] position, let’s say they’re the head of engineering, they don’t really care how it gets done. I mean,

[00:22:54] to some degree, maybe they have some principles that inform them. They care that you’re not

[00:23:00] doing harm in order to accomplish your goals. And they probably don’t want you spending an

[00:23:05] exorbitant amount of money, but they’re probably ready to spend some money, right? Otherwise,

[00:23:11] they wouldn’t hire engineers. And they’re also probably ready to not have to think about

[00:23:18] all of the details, once again, why they’ve hired engineers, right? So if they can delegate

[00:23:25] responsibility, your capacity to take responsibility for something is highly correlated to your

[00:23:33] capacity to be promoted. Yep, exactly. And that’s where also then the autonomy that everyone’s

[00:23:41] dreaming about comes from is if they can delegate responsibility to you, that automatically also

[00:23:49] gives you a lot of the autonomy that so many engineers want. But let’s be honest, most

[00:23:54] engineers just aren’t actually ready for as much autonomy as they want. Right. Because most engineers

[00:24:01] want the autonomy to go and do the thing to the spec, right? But they’re not ready for the autonomy

[00:24:09] of making the decision and carrying the responsibility, whether it fails or succeeds.

[00:24:17] Exactly. It’s heavy. It’s not an easy thing, right? I think that’s another important

[00:24:26] message that at least I want to get across, and I’m sure you do too, that just because

[00:24:32] maybe this is more accessible than the folks listening might have thought originally coming

[00:24:39] into this episode, it does not mean that it’s emotionally easy. It doesn’t mean that it’s

[00:24:46] intellectually easy or relationally easy. None of this is necessarily an easy thing,

[00:24:55] but it definitely has a more natural path than maybe most engineers might intuitively expect.

[00:25:05] Yeah. Yeah. And I think the hardest part of autonomy and probably the thing that makes

[00:25:12] it most likely that you’re going to get more autonomy and more responsibility is when it

[00:25:15] goes wrong. It’s very hard, but what you really have to do is say, I messed up. It went wrong.

[00:25:24] Here’s why it went wrong. Here’s how it’s not going to go wrong next time. And this is what

[00:25:29] I’m doing to fix it. That’s how you get more responsibility next time, but it’s really hard

[00:25:35] to do that. Yeah. One of the most important things that you can do when looking for a role

[00:25:45] for folks who are looking for their next job is ask what happens when things go wrong here.

[00:25:50] Mm-hmm. If the culture supports that opportunity to say, yeah, sometimes things do go wrong. That

[00:26:00] just is par for the course. It’s going to happen. What we expect when things go wrong is that you

[00:26:06] learn from it, that you apply your learning in some way, that you actually have a plan for how

[00:26:12] you’re going to respond to the failure. Those are the things that you look for. And instead of

[00:26:19] you know, cultures of fear or blame or those other pieces that make that incredibly uncomfortable,

[00:26:28] you get to experience failure and that kind of rebound or response to failure,

[00:26:35] that is a huge growth opportunity. And to your point, that’s where you learn to have

[00:26:41] that autonomy that is actually useful. Mm-hmm. Yeah, because it’s easy to show

[00:26:49] ownership when everything is sparkling gold and going awesomely. But the real ownership is what

[00:26:55] do you do when shit hits the fan. Mm-hmm. Yep, absolutely. Well, Swiss, thank you for

[00:27:05] joining me to discuss this. I have a couple of other questions, but before we get into those,

[00:27:11] I want to ask you, for engineers who are listening to this and they just want a lot more of this

[00:27:17] discussion because we haven’t covered all of the points that we could, where should they go? What

[00:27:22] can they learn from you more on this subject? Yeah, so I have a tiny little website called

[00:27:29] seniormindset.com where you can get a series of emails or essays that I’ve written about this

[00:27:38] over the last couple of years as I’ve been learning about it and essentially a collection

[00:27:44] of my most impactful essays on the mindset of a senior engineer. And they’re currently also

[00:27:52] being packaged as an ebook. And probably by the time you listen to this, the ebook is going to

[00:27:57] be out and you can binge read the whole thing because apparently the essays are good enough that

[00:28:05] the best feedback, the most feedback I’ve gotten were people saying, yo, can I stop waiting for

[00:28:09] the next essay to come in email? Can I just binge read this whole thing? So that’s how the ebook

[00:28:16] happened. Yeah. Excellent. So that’s seniormindset.com and you can also go to swizzes.com,

[00:28:22] which is my blog where it’s a little bit more off topic and more technical and mindset kind of all

[00:28:30] mixed together. Perfect. So seniormindset.com, that will be likely in the show notes, assuming

[00:28:40] I remember to write them correctly. That should be in the show notes. I do have two questions I

[00:28:46] like to ask guests who come on this show. And we’ll start with the first one. What do you

[00:28:53] wish more people would ask you about? Oh, that is a really good question. What do I wish more

[00:29:00] people ask me about? Wow. Nobody has asked me that before. I think one thing is that I keep harping

[00:29:15] people on is how to think more in probabilities and statistics and making bets rather than

[00:29:26] looking for perfect answers to everything. You’re on the right show. We could talk about that

[00:29:33] for a whole nother episode, I think. Tell me more about your thinking on this.

[00:29:38] Yeah. So a lot of this has been brewing for a while and then it really solidified when I read

[00:29:48] Thinking in Bats by I think Annie Duke. Yes. Annie was actually on this show talking about

[00:29:54] thinking in bets. Yeah. Nice. Yeah. So I found that book to be really impactful. I really liked it.

[00:30:00] And it’s basically, you can never really make the perfect decision, but you can look at the

[00:30:07] odds of the different options you have and make the best possible decision and then go with that.

[00:30:14] And where I’ve really applied that in engineering is being able to say,

[00:30:18] this is not worth fixing because it doesn’t have a big enough impact, doesn’t have a big enough

[00:30:23] expected value. Let’s fix this other thing. Or just evaluating different options of how to

[00:30:30] implement something and just taking a bet and choosing one of them and being very comfortable

[00:30:34] with that because I know I’m not going to regret the decision because just because the outcome is

[00:30:42] bad doesn’t mean the decision was good and vice versa. Just because the outcome is good doesn’t

[00:30:46] mean that a bad outcome doesn’t mean it was necessarily a bad decision and a good outcome

[00:30:54] doesn’t necessarily mean it was a good decision. So thinking about it that way has really helped me

[00:31:02] make decisions faster and be able to be that person on the team who can almost parachute into a

[00:31:10] technical meeting and five people are discussing something and they can decide how to solve the

[00:31:17] problem. You can listen to everyone’s input and just make a decision because you’re comfortable

[00:31:22] making those bets and say, let’s take this way because X, Y, and Z. And then if it doesn’t work,

[00:31:29] I’m going to take the heat because I made the decision.

[00:31:35] It’s amazing how many of these pathways are worth exploring more in depth. Certainly,

[00:31:44] the book is worth reading as well. Something that you mentioned is that,

[00:31:51] well, two things I want to touch on. One is it has been fairly easy for me when I talk to people

[00:31:57] about this subject that a bad outcome doesn’t necessarily mean a bad decision. Most people can

[00:32:03] kind of get there like, oh, okay, yeah, I can understand how you wouldn’t be able to know what

[00:32:08] the outcome was. Sometimes good decisions go wrong. That’s okay. Sometimes really great

[00:32:18] quarterbacks or whatever sports you follow, sometimes they lose games. The best teams lose

[00:32:24] games too, right? The other is much harder to get people to accept, which is a good outcome

[00:32:32] doesn’t necessarily mean a good decision. Intuitively, we think that it’s impossible

[00:32:37] to have a good outcome with a bad decision, and that’s not true, right?

[00:32:44] Yeah. You can run a red light and you don’t crash, but running a red light is still not a good

[00:32:49] decision. Right. Even more extreme things like you could have a very successful startup

[00:32:59] as a result of a series of strokes of luck, basically. Even if you make a bunch of bad

[00:33:07] decisions, it doesn’t necessarily mean that those positive outcomes that you’re enjoying

[00:33:15] are because of those decisions that you made.

[00:33:18] Yeah. It’s like they say in business, sales covers all things.

[00:33:27] Yeah, that’s good. I’ve seen the results of previous good decisions that end in good outcomes

[00:33:40] could absolutely be influencing what you’re thinking is a more localized decision, which was

[00:33:47] a bad one, having a good outcome. It’s actually because the good outcome is still trailing from

[00:33:52] that previous decision, right? An example of this is if you’ve built a really great brand

[00:33:58] and you’re selling products and you come out with a really bad product, but it’s carrying

[00:34:05] that really great brand, it still may have a decent sales quarter because it has that brand.

[00:34:12] Yeah. Yeah. You see that a lot in very big companies where they would have to mess up

[00:34:19] so many decisions in a row for the money printing machine to stop. It’s almost impossible to tell.

[00:34:26] Yeah. This is a whole other class of problems to solve, certainly.

[00:34:34] I like what you’re saying here at the more atomic level that because you have these tools of

[00:34:41] reasoning where you can apply this kind of statistical thinking, you can come into a

[00:34:46] meeting where you didn’t really have a lot of context. Assuming that you can ask the

[00:34:51] right questions and get accurate info from the questions that you’ve asked,

[00:34:55] you can help make decisions. You can be the operator in the room that helps wade through

[00:35:05] what other people are having trouble wading through.

[00:35:09] Exactly. That’s another way to force multiply your team is to help unblock them on those things.

[00:35:15] Yeah, absolutely. I’ve also noticed with this idea of being a statistical unblocker,

[00:35:27] that a lot of people have somewhat of a way of saying, oh, this is more likely to succeed than

[00:35:33] this other thing, or given two options that they can’t really tell the difference between them,

[00:35:39] they’re just going to go with the one they like. Another kind of statistical thinking that I’ve

[00:35:47] tried to help introduce to my teams is the second order thinking. In other words, yes, you may have

[00:35:53] two equal options on their face, but what are the downstream effects? Or is one of those options

[00:35:59] easier to reverse the decision on? If they’re otherwise equal, then the one that’s easier

[00:36:06] to reverse is probably a better option. Whatever that second step is, I think a lot of people

[00:36:17] intuitively don’t think about the second step as a core part of the decision.

[00:36:23] When you’re writing code or designing solutions, thinking about what is this going to encourage,

[00:36:29] what kind of behavior is this going to encourage in the rest of the team?

[00:36:33] Can I write this code so that it’s not just this code that’s good,

[00:36:37] but so that also others who are following these patterns by accident, almost by accident,

[00:36:43] write good code as well? Yeah. Yes. Yeah. And trying to follow good practices as a modeling

[00:36:52] step rather than just for this specific problem. Yeah.

[00:36:56] Yes.

[00:36:58] Swiss, thank you again for taking the time. I have one final question for you,

[00:37:02] and hopefully it’s a relatively short one. If you could spend just 30 seconds giving advice

[00:37:07] to engineers of any background and experience level, what would you tell them?

[00:37:16] I would tell everyone to read How to Win Friends and Influence People and read The Goal. I think

[00:37:24] those two books will have a bigger impact on your career than all of the technical books you could

[00:37:33] read, assuming you already know how to code. Wow. Yeah. So you’re pointing folks to these two books.

[00:37:42] So the first one was How to Win Friends and Influence People. Most people have probably

[00:37:45] heard of that one. The second one, I don’t know that I’ve heard of. What was the name of the book?

[00:37:50] The Goal. It’s from something Goldrat, and it’s about the theory of constraints. It’s actually

[00:37:58] a management book talking about manufacturing, and it deals a lot with how to have smoother

[00:38:11] manufacturing processes. What is the actual goal of manufacturing? So that’s where a lot of my

[00:38:17] ideas earlier come from, where why do you even do engineering? Well, it’s because the business

[00:38:23] wants to achieve some goal, and that’s actually the goal of engineering. It’s not the coding itself.

[00:38:30] And then if you want to dig deeper into more of that, into that stuff, there’s kind of spiritual

[00:38:35] successors to the goal are the Phoenix Project and the Unicorn Project, where it’s more specifically

[00:38:42] theory of constraints applied to software engineering and IT systems. And that’s also

[00:38:48] where the whole then DevOps movement comes out of, et cetera. Absolutely. Yeah. Excellent.

[00:38:58] That’s kind of a cheat code because you’re giving 30 seconds of advice to go and read

[00:39:02] for a couple of hours of that info. So that’s great. Thank you so much again. And if you’d

[00:39:10] ever love to come back or ever would like to come back on the show, we would love to have you

[00:39:15] come back. But otherwise, once again, if you want to hear more from Suez, head over to the

[00:39:23] SeniorMindset. That’s seniormindset.com, not the seniormind, but seniormindset.com.

[00:39:30] And what else can we share with listeners about where they can find you online?

[00:39:35] Yeah. seniormindset.com or swissets.com. Or probably if you just put Swizzet Stellar into

[00:39:41] Google, you’ll find a lot of places where you can go from there. Excellent. So let’s thank you again

[00:39:48] for joining me on Developer Tea. Thanks for having me. That was fun.

[00:39:54] Thanks so much for listening to today’s episode of Developer Tea. Thank you again to today’s sponsor,

[00:39:58] LaunchDarkly. You can get started with feature flags that won’t break on you and will help you

[00:40:03] deliver faster and more frequently to your users with much more confidence. Thanks so much for

[00:40:09] listening to this episode. Thank you again to Swizz for joining me once again at Swizzet on

[00:40:15] Twitter and seniormindset.com. Go and check out everything he is creating there. If you’d like

[00:40:22] to discuss this episode or anything about your career or your life as an engineer, you can join

[00:40:28] other engineers who have that same desire. Head over to developertea.com slash discord.

[00:40:33] That community is totally free and it always will be for listeners of this show. Thanks so

[00:40:38] much for listening and until next time, enjoy your tea.

Visão de gráfico