What If The Real 10X Developer Is The Friends We Made Along The Way?

Jason Lengstorf: [0:00] Hey, everyone. Today, I want to talk about the idea of 10x developers and specifically what that means, because I think that a lot of times, when we talk about what a 10x developer is, we get lost a little bit in the details. I want to flip that on its head a little bit because I think that there is a way to be a 10x developer, but I don't think it's in the sense that we usually hear.

[0:25] What we usually talk about when we see people talk about 10x developers is people who have an incredibly high output as a developer. That's what you're looking at when you see a VC say, "Oh, yeah, make sure that you hire a 10x developer. They're going to write most of your code base. they're going to be a rock star," and all that kind of stuff.

[0:45] While I can see where that sentiment comes from, I think that what that is is a misunderstanding of what 10x outcomes are, because if you're focused on the output what somebody does, then you can lose sight of the outcome, which is what the impact of that is in the second, third, or fourth order.

[1:06] I want to dig into that a little bit today, because I feel like there's been a bit of a stigma attached to the idea of being a 10x developer and rightly so. When we think about it as someone who is completely focused on output at all costs, that's not a good situation.

[1:22] We'll dig into why here in a minute. I do think that there's a way to have a 10x developer, but I don't think that it looks anything like what most of us would expect. That's what I want to talk about in this presentation.

[1:35] Where we start with this is we have to differentiate between output and outcome. We have to talk about what the differences are between the two because it might sound on the face of it, like quibbling over syntax. Really, the semantics of this are minor but important.

[1:51] When we talk about output, we're talking about someone who is creating an exceptional amount of code. We've all worked with people like this, or maybe we've been this person, where we can sit down and crank out thousands of lines of code. Usually, we can solve problems. That kind of output is what really turns heads on the surface.

[2:12] That's what you'll see people put into their sound bites or what you'll see in articles or books about how to grow a company is look for somebody who's a 10x developer. What they're talking about is someone who's going to write all the code really fast, but what we're really looking for is not someone who puts a bunch of code together because what does that code mean? What does it do?

[2:31] If I write 50,000 lines of bad code, I did 10x the output, but was it a good output? How do we know if it was quality? How do we measure that qualitative impact? The way that we do that is through outcomes. Outcomes are what happens once we have done the things that we do.

[2:49] If I generate some output, it will have an impact. If I cook a good meal, that's great. I cooked a good meal, but if I immediately throw it in the trash, that's a sad outcome. The joy of cooking is not having made a meal. The joy of cooking is enjoying it with friends. The outcome is that enjoyment. The outcome is a feeling that you have.

[3:09] When you talk about that in terms of a company, the outcome of being a 10x developer is that I have solved the right problems. I've worked with my team. I've made the company move in the right direction so that it's a sustainable, effective, and functional company and team. Those are really, really important differentiations.

[3:30] I could write 50,000 thousand lines of code, and ultimately down the line, the company's infighting. It's not moving in the right direction. We're not solving the right problems. We fold up and go home. All my code is for nothing because the company doesn't exist anymore.

[3:45] I could, by contrast, write 5000 lines of code but focus on the outcomes, and the company learns to work well together. We all are focused on the right goals. We're asking the right questions, and we solve problems that people need solved.

[3:58] As a result, my 5,000 lines of code in combination with the greater output of the team leads to the outcome we all wanted, which is that the company succeeds. We all make more money. We all have a better career. We all have more opportunities. It's really important that we differentiate that.

[4:15] I want to do this by digging into a story. Let's look at two fictional developers. We'll walk down a path of one who is focused on output only and one who's focused on outcomes. When you start looking at the output-driven developer, it starts out really great. Over time, it starts to take a turn. We're going to look at how that goes.

[4:37] Here's a progression that I've seen. This is not me being hypothetical. This is what I've seen happen to myself in my earlier days when I ran an agency and with coworkers when I worked in other companies.

[4:49] The first thing that happens when you are a 10x output-driven developer is that you become the favorite. You are in unbelievably productive. You can put out tons and tons and tons of code really fast. Somebody will throw you a problem. You go away in a hole. You just chew it up and spit it out, and you've got a solution. That makes you extremely popular with people who want instant results.

[5:12] However, that leads to you becoming the company's top contributor, which on the surface, that feels pretty good. It's always nice to be important, and it's always nice to feel like somebody who is moving the needle. Being the top contributor across your entire company's code base can feel really good in sprinter sense, like, "Hey, I'm doing all this stuff. Look how much I'm moving."

[5:37] The tradeoff there is when you've written most of the code, you also become the de facto owner of most of the code. That is really stressful, especially as a company scales. As you start to own things, you are too stressed to do the work to onboard other people. That means that you are permanently on call.

[5:59] Because you wrote most of the code, because other people weren't in that code and don't have a lot of context, you are the person who has to fix all of those problems. That's stressful, and it leads to one of the things that I like at least, which is that you literally can't leave. How do you take a vacation when you're the only person who can fix problems that come up in production?

[6:21] I've worked with people who tried to go on vacations and spend their whole vacation getting paged at five o'clock in the morning because some production system wasn't even down, but a team was blocked. Multiple engineers were just sitting idle because they didn't know how to move forward.

[6:36] That means that the option is we can let this person have their vacation, or we can page them and unblock these engineers who are all getting paid an hourly rate. It becomes a economically bad situation where it sacrifices this individual, this 10x output developer.

[6:58] It costs way too much to let them be idle because other people get blocked. It means that this developer is now stuck until they basically flame out. I've never seen one of these developers fix the situation. I've only seen them leave.

[7:13] This is not a good outcome. That leaving is horrible. It underlines this problem, which is that 10x outputs wreck teams. When you have somebody who is the rocket booster that's driving an entire team, it can move the team really far, really fast.

[7:34] Rocket boosters burn out. If you've ever seen a rocket launch, the boosters do a huge amount of the work. They flame out. They drop into the ocean, and they're just useless.

[7:46] If you've ever watched a friend or a colleague or if you yourself have burned out, you know what that feels like. Suddenly, everything stops working. That is just a personal impact. If you've seen somebody burned out, that is not a fun thing to do. It's not a fun thing to watch. It's especially rough if that person who burned out was the linchpin in your entire team.

[8:10] If you have ever inherited a system, and somebody has said, "Well, we don't know how that works because the person who built it is gone, and we don't know what it does anymore." That doesn't feel good. It's not empowering.

[8:23] When you have somebody who's doing that 10x output, they're moving so fast, and they're optimizing for going quickly and not bringing anybody along. It starts to build this system in your company where your company feels like a little box that you are protecting as the 10x output developer.

[8:43] Nobody knows how to contribute. They don't know how to get into this code base, so they just back away. They're like, All right, well, I guess if you're going to do it, you're going to do it," but then you're doing the opposite of what you want in a good team.

[8:55] You're creating learned helplessness, and you're creating a single point of failure. You're making that 10x output developer the entire bottleneck for your company.

[9:04] If they're the only person who can work on a section of the code base because they wrote 95 percent of it or 100 of it, and they haven't done a good job of onboarding anybody else, that's really expensive for the team because, again, no vacations. If they quit, what do you do?

[9:20] I've inherited systems where the solution was...We just scaffold a new software on top of the old software because we didn't know how to fix it. We just built stuff on top of it to change what it does. That's how our life is now.

[9:34] You have these geological strata of software where somebody builds a bunch of stuff, and then somebody else doesn't learn it. They just build on top of it and then build on top of that. You end up with a lot of problems based on that approach.

[9:50] That output, as tempting as it is to just say, "Oh, don't worry. Trust me. Let me go in a hole. I'm going to solve this problem. I'll bring you back a win," that feels really good. In very limited doses, that can be a great thing.

[10:05] On a longer time horizon, that is just a devastating blow to a team for all sorts of reasons. If you've ever sat with a piece of code and had somebody say, "It would take me longer to explain this to you than to just do it myself."

[10:22] That is not a fun thing to hear. It doesn't make you feel like you're a contributing member of the team. It makes you feel like you're asking permission to do your job. That feels terrible. There's no worse feeling in the world than wanting to do a good job and feeling like you have to go to somebody and say, "Please, can I do my job?" You're not going to build a great team that way.

[10:43] This is the cautionary tale. This is the worst-case scenario. Let's talk a little bit about what the opposite of that is. Let's talk about what the 10x outcome would be. A developer who's focused on 10x outcomes is going to, first and foremost, be focused on context because context is the hardest thing in software development.

[11:02] It's the reason that when you build something, it makes perfect sense to you. Then you walk away and come back six months later, and you're like, "What was I writing? What was this code?" We build complex mental models in our head that help us understand and think about code.

[11:15] If we're not sharing those with the people around us, then they never have that model that lets them understand why decisions were made. Before that, before we write any code at all, we should have a good understanding of what the company's goals are, why the thing we're doing is important, and why we're doing it now versus other things on the roadmap.

[11:33] If we can get that context clarified and shared with everyone on the team, it's a lot easier to trust the whole team to work together and for all of us to understand why things are being done the way they're done. That helps avoid that problem of going in a whole and coming back with a solution that nobody else knows how to touch.

[11:53] They're also going to focus on solving problems together, pair programming, good code review the occasional mob programming, getting in a room together, and talking through how to solve a given problem.

[12:03] Walking through your own code or somebody else's code with people is a great way to not only understand what's going on and get a better feel for a code base and how we can maintain it together. It's also a good way for us to get into as a collective mindset around writing code.

[12:21] If you and I talk about how to do a thing for long enough, we're going to start to naturally drift toward standards. We're going to make group decisions around style and approach and whether we should do things this way or that way.

[12:34] All those decisions start to get made together and will drift toward consensus. There's no need for anyone to mandate or top-down really stringent rules that they then have to enforce. We just start to do it together.

[12:49] The other thing that a 10x outcome developers going to do is they're not going to be focused on their own work as much as they're focused on the entire system, how things are fitting together, because their work is only part of the whole. If you are coming in and you want to be a driver of 10x outcomes, your work is the thing that you do to enable the whole team, the whole company.

[13:11] You should be looking at how all of these pieces fit together. When you're talking about a project, you might know what you're doing, but does everyone on your team have clarity on what they should be working on? If not, you should notice that blocker.

[13:25] If that blocker is challenging, a 10x outcome developer is going to tackle that hard problem. They're going to dive into the sticky things. If a project is tough, feels like eating a big plate of frogs, the 10x outcome developer is going to eat the biggest frog first. They're going to try to figure out what's going to unblock the largest number of people on the team.

[13:43] Then they're going to build that. They're going to pull the team in. They're going to pair program on it. They're going to find a way to get everyone unblocked so that everyone can move. By creating that context, by working together, by noticing the blockers and tackling them, you get to the point where the entire team is starting to move quickly.

[13:59] It might be a little bit slower to start, but ultimately, everyone is moving. They're moving at speed. If a 10x outcome developer is getting people moving at speed, you also have to keep in mind that this is code that's going to be maintained. I said a minute ago, if you write some code and come back to it six months later, it's like, "What was I thinking? Why don't I make the decision that I made?"

[14:22] If you're thinking about maintenance, you can limit the impact of that. You can make it so that stepping back into this code later, when you've forgotten all of the contextual stuff, the mental model that you built up in your head.

[14:33] If you can get to the point where that code feels familiar enough, you can walk back to it and say, "OK, I don't really remember what I was doing here, but I do know that this makes sense, and this makes sense, and this makes sense. I can get back to a working model pretty quickly, add new features, do any of those chores that come with older code."

[14:53] If you're thinking about maintenance, you can architect the software in such a way that that doesn't become a nightmare. You can be thinking about maintenance, add some code comments, write a little ReadMe, do a little video demo. If you've got some particularly gnarly business logic, just take a minute and explain it.

[15:11] These are all things that will make it easier later on when you come back. The whole team then can join in and help with that maintenance. It doesn't become just your problem. That creates problem -- my favorite thing -- which is a really high-vacation tolerance on a team.

[15:26] If you have a team where everybody has context, everybody has worked on the code, everybody mostly knows what's going on, then if somebody goes on vacation, even if it's the lead on the project, people aren't stuck. Nobody's unable to move because they all know enough about the project that there are things they can do.

[15:47] That, I think, is such a powerful outcome. Again, what we're trying to do here is we're trying to get to the point not where you are the linchpin and the only thing that moves the company forward. That's fine if you're a freelancer, but if you work on a team, the worst outcome is that one person is carrying the load that drives so much resentment and just frustration and lack of autonomy.

[16:12] The best possible outcome is that everybody feels empowered to do work. They feel like they can do it well because they all understand how and why things are done. By doing that, you can take time, you can let anybody on the team, go take a vacation because there is no bottleneck. There is no point where one person can leave and the whole system falls down.

[16:33] That is the great outcome that we're all after. 10x outcomes are essentially built around growing teams because a really healthy company is an organism. Each person on the team is part of that organism but not the entire organism. The reason that life is resilient is that you can't kill all life by removing one piece.

[16:56] You have to have the whole system built to be resilient to make up for issues. By building teams that are designed that way, that are designed to handle one person being out or something changing, all of those things are skills and design decisions. When it comes down to it, you're architecting your teams. You're architecting your software. You're architecting the way that you work.

[17:23] Each of those design decisions is going to lead to a healthier, more resilient team, or a more closed-off siloed and failure-prone team.

[17:33] Let's talk about real strategies, things that you can and should be focusing on, especially if you're in any kind of leadership position, whether that is being an architect or an engineering manager, or whether you are the tech lead on your team or just the most senior person on your team.

[17:50] If anybody's looking up to you for guidance, you're in a leadership position. That means that you can help affect these changes. You can drive these outcomes in your company.

[17:59] The first and foremost thing is that trust comes first above all else. If you don't have trust, you've got nothing. You can't do other things if you don't have trust. If I don't believe that you're doing the things you're doing for the reasons you say you're doing them, we're done. We're dead in the water if that trust isn't there.

[18:17] It's really, really important that if I am going to be in a situation where I'm working with you that anything I say to you is true. If I tell you I'm going to get something done, I do it. If I tell you that you own something, I'm not going to come take it away from you or second-guessed you.

[18:32] I'm going to trust you to do your work, and I'm going to trust that you're going to trust me to do mine. That's really, really important that we give and receive that trust. That's the foundation of everything and a healthy team.

[18:44] It's also incredibly important that we set clear expectations. If I'm going to do work, I need to know when it's done. I need to know what's expected of me. We have to have those uncomfortable conversations at the beginning of a project where we say, "OK, I'm unclear on what this means."

[19:02] The worst outcome is a joke when we talk about working with clients, and the client says, "Mm, make it pop more. I'm not sure what I want, but I'll know it when I see it." If you've worked on a team where that's the type of direction that you get, you know how demoralizing that is. You don't feel like you have control. You don't feel like you have clarity. You're just working and hoping.

[19:24] That's frustrating. It can feel very sloggy. It undermines that trust, because if somebody is telling me to do work, but they can't tell me what work to do, then do I trust their leadership? Do I trust their decision making? It can undermine all of that and start to tear the team apart.

[19:40] Have those conversations. Try to get down to really clear black-and-white, yes-or-no, true-or-false answers of what something is when it's done. How do I know for sure that this is complete?

[19:51] I can hand it to you, and you will say, "Absolutely yes, that is what we needed." A lot of that comes to scoping things down, being small and clear, and focusing on next steps and not five, six, seven steps in the future.

[20:04] We also have to keep in mind that code is a social endeavor. When I write code, it's not just me writing code, turning it in, and then no one ever looks at it again. Code is a medium for communication. I am making decisions.

[20:16] Those decisions will be dealt with by the people using the software, the people maintaining the software later on, my teammates when they code review it, if we're pair programming, all of those things. We are using code as a medium for communication. It's also important that if we're working on a team, that our code is part of the way we work together.

[20:36] We're not people who have meetings, then break apart and work individually, and then smash our completely unrelated code together. We've potentially all worked on teams like that. I know I have. It doesn't feel good, and we don't get much done. Instead, if we're focused on things like pair programming on good code review practices, then our code becomes part of being a team.

[20:56] One of the things that I think especially now when everybody's remote, we used to have lunches or we would just walk down the hall with somebody. You would have chitchat. You have these off-topic conversations. That is the basis of trust. We don't necessarily have to be best friends, but when I go to work, I should feel some connection to you. That's the trust that lets us function.

[21:19] Pair programming, mob programming, those are spaces that create an opportunity for us to get to know each other beyond just people I write code with. You have to be at least close enough that you can function together because that familiarity is the foundation of trust.

[21:39] Designing for deletion is more software architecture, but I think it's important, because a lot of times, we don't have time to thoroughly document in an evolving system. We can go through, rewrite all the docs and all the connections, and get everything fixed. Instead, what we want to do is scope down our projects and create very isolated chunks of code that have very clear boundaries.

[22:03] That doesn't necessarily mean that they're not part of even the same repo. It just means that when we think about how things connect to each other, there's a clear API. That could be REST. It could be GraphQL. It could just be a utility function that gets passed back and forth.

[22:18] Ultimately, what we're going for is the situation where if I'm accessing data, I should be accessing data through a utility function or an API endpoint. When I do that, I shouldn't have to care at all if that data is being pulled in by my SQL database or if it's coming from Postgres, Mongo, or whatever. That part doesn't matter to me.

[22:38] I just know that, in my app, I call get_post from database or get_users by ID. Those calls are an abstraction. They're a clear boundary between one part of the app and another so that later on, if I need to make a change to my database, I don't have to rewrite all of the code that uses that data. I only have to rewrite the utility.

[23:01] If I can get that utility rewritten in such a way that the data it returns is the same, then there's no switching costs for the rest of the code base. We can fully hotswap an entirely new platform by just honoring that contract with the newly built software.

[23:15] If we optimize our code that way, that means that it's easier to train on. It's easier to onboard. It's easier to maintain, because without that optimization for deletion, our code starts to get leaky. We'll see that what started out as a chunk of code here starts to spider web out into the rest of the code base.

[23:34] We've got these weird dependencies and things that somebody is using something away that wasn't intended to, or they're using an underlying function that can never be changed. It just makes rewrites hard. It causes unexpected breakage. It causes weird to upstream problems when you start making changes later on.

[23:54] This is something that will make maintenance easier, but it also just makes it easier for the team to understand things because you don't have to learn a several hundred, thousand line code base.

[24:03] You can just learn the little bit of code that you're working on. Maybe, that's only a few thousand lines for data. That makes handing things off, onboarding new teammates. All of that gets much more approachable. That leads to stronger, more resilient teams.

[24:20] It's also important to keep in mind. We should never be nice. Being nice is a short-term solution that causes more long-term problems. Instead, we should be kind. If you are doing something, it is causing a problem for me, I decide to be nice about it, and don't say anything, that didn't solve the problem.

[24:41] It's just going to get more and more troublesome for me, and it's going to lead to me eventually blowing up at you. That's not a good outcome for either of us.

[24:51] Also, if I'm doing something that bothers you, and you're being nice to me and not telling me about it, I'm going to feel betrayed if I find out two years later or in my next performance review that something that I wasn't even thinking about that I didn't want to do was bothering you. I would have changed it in a heartbeat if I'd known.

[25:11] This is why trust is so important because I have to make the trust number one so that everyone feels confident. If you come to me with a problem, you have to trust that I'm not going to punish you for that, that I'm not going to use this against you, that I'm not going to go behind your back and try to sabotage you.

[25:30] If that trust isn't there, we can't have the honest conversations. We can't be straightforward and share, like, "This is what we're doing. This is the kind of team we want to be. Let's be better together." That all relies on trust, and it relies on being kind. Sometimes, the kind thing is difficult to do.

[25:51] We also have to focus on setting the right example. As leaders, whether we're just the most senior person on the team or whether we're the VP of engineering, we are going to be in positions where other people are looking at what we do, and they're going to model after that behavior.

[26:07] If you are in a community, if you are on Twitter, if you are writing an email, if you're talking to someone on your team, the way that you talk, the way that you act, the actions you take, the way you write code, the way you treat people, all of those things are subtle indicators for the way things are at this company, on this team when dealing with me.

[26:27] If I'm living the values that I want everyone to have, it's that much easier for people to have and adopt those values. That is so important when we're talking about trust and safety because the worst thing in the world is to have somebody who says, "Oh, I really value this," and then they do something that completely undercuts that.

[26:47] You want to go someplace where the behavior is backing up the words, or even better, the behavior is speaking so loud that you don't need the words. That's the kind of thing that we have to start. We are the ones who get to make these decisions if we are in any position of authority.

[27:06] Even if it's just one person on our team who looks up to us, we can be the person who starts that ball moving. We can be the ones who look around to the rest of the team and say, "Hey, let's be better. We can start the idea. We can bring pair programming. We can bring a better code review process. We can talk about how we can build more trust on the team."

[27:27] That's how we set this example. That's how we go out, push these things forward, and make the difference so that everyone on our team feels that trust, feels that security, and has the ability to progress, build, and work in a company that is extremely functional and getting those amazing outcomes.

[27:44] We all want to be on one of those teams that blows people away, but we have to remember those teams weren't hired. Those teams were grown. People who come into teams look around, look at how people are treated, and look at how people act. That's who they become. You can hire somebody and show them a great company, and they will become an excellent member of an excellent company.

[28:06] Or, you can hire somebody great, bring them into a toxic culture, and then reinforce that toxic culture. You're going to either lose them, or they're going to become just as bad. If you can't hire away company problems, you have to work within the team to build the team you want and then bring more people who are going to help drive that culture into an already-changing, already-healthy culture.

[28:29] This isn't a problem you solve with money. It's not a problem you solve with hiring. It's certainly not a problem you solve by going out and hiring somebody whose job is to make the company healthy. You have to live and bring these values. If you want a company that's not built on, protective and...

[28:50] Like, "I write all the code. Nobody touched my code." You want companies that are full of people who get it, who are interested, who are engaged to have autonomy, who feel excited to work, who feel trusted to do great work every day, and who -- because of all of that -- have the ability to grow, excel, and then hire more people who they can teach to grow and excel.

[29:11] That is what a truly 10x company looks like. If you want to be a 10x developer, you need to be driving that change. Be the catalyst for that change and help create that outcome at your company. Thank you very much.