Crafting Code Podcast

[00:00:15] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about the application of lean software concepts.

[00:00:28] Dave Adsit: And I'm Dave Adsit, a VP of engineering, and I have been thinking a lot about using different tools in different roles, specifically the importance of learning about people, psychology, and motivations as you move from an individual contributor to a manager in a socio-technical system.

[00:00:45] Allan Stewart: This episode's topic is creating impact as your organization changes. I think this is a question that you've heard a lot, Dave, as a people manager, you hear about people asking, how can I create?

[00:00:59] Dave Adsit: It certainly is. It probably comes up every week in one-on-ones, not always by the same terms, not always with the same question, but developers ask me all the time, how can I create more impact? Am I creating enough impact in my role? Do I deserve to be here? Am I doing enough? And it comes down to impact a lot. People want to see that the work they do, the contribution they make actually has a positive impact on the company, the team, the business, the users, et cetera. Yeah.

[00:01:34] Allan Stewart: So we'll talk about a couple of different scales or a couple of different axes upon which you can have impact. So to start off, we're going to talk about different scales of just the number of people, because this one kind of takes us from the world of the obvious to the unknown, because if you're in a tiny startup. Maybe you're the technical founder or you're the first developer, the first technical person on the scene, the first person to write code. Then your impact is pretty obvious. Anything you do makes an impact.

[00:02:11] Dave Adsit: Yeah. Anything you do makes an impact. Anything you don't do doesn't get done from a technical perspective. If you are that team of one, you're the, what do they used to say? The army of one. You're the only one writing code. You're the only one deploying code. You're the only one building the website. It's obvious what your impact is. And it can be very rewarding. It can be very terrifying because if it's not getting done by you, it's not getting done at all.

[00:02:39] Allan Stewart: Yeah, I think there's some interesting questions around how much can a single developer do all by themselves? And this isn't limited to just you're the only one. But just any time that we're thinking about our individual impact, well, what can you do? How much can you get done by yourself? Because there's kind of an interesting swing between the concept of small teams can do great things versus you need more people to be able to do more work. There is an upper limit. I can work eight hours a day, seven days a week. I can work 20 hours a day, seven days a week. 24 hours. At some point, that doesn't work. You can't work 24 hours, seven days a week because you burn out. Eventually, you will fall asleep or die. And so there's an upper bound, right? You can't get more done if you're just the only person there.

[00:03:38] Dave Adsit: Yeah, and honestly, I've maintained some code that I've written at the end of a 12 or 14-hour stint. And it's not as easy to maintain as the code I wrote in the first four to six hours. Or eight hours. Definitely. There's that old aphorism, like, if you want to go fast, go alone. If you want to go far, go together. I think that applies a lot here. It's easy to see yourself making a ton of progress when you are the only one working on the thing. You understand the entire system because you've written every line of code. You can probably hold the entire domain, the entire object model for the system in your head. You know where this is done. You know where that is. You know when to touch the database and when to execute in code because you're making all of those decisions yourself. That can be very, very empowering. It can also lead to analysis paralysis pretty quickly. If you start to have questions about should I do X or Y, you can start to really spin out pretty quickly. You don't have anybody to ask. And you don't have that safety net of a second brain also approved of this thing I am doing. So I think it's very obvious, as you stated, that it's obvious what your impact is if you're the only one. And it's easy to see progress that you're making and how it is changing the face of the product, the face of the company, whatever. But eventually, if things are going well, then you start to see the desire to grow that team. For a lot of very good. The first reason is almost always because we want more. If we hire a second developer, we'll get twice as many lines of code produced, therefore twice as good, therefore twice as much, right?

[00:05:31] Allan Stewart: And from the get-go, everything is wrong.

[00:05:36] Dave Adsit: Right. I'm sure that's how every non-technical founder of a startup thinks. When I hire my second developer, I get twice as many features per week. But there's other good reasons to hire, right? One of them is you want to reduce the bus factor or the lottery factor. But mostly in engineering spaces, we talk about the bus factor. We're not as optimistic as the marketers. You don't want your entire code base to become inscrutable if a single person is hit by a bus on their way to work.

[00:06:11] Allan Stewart: I've been told from a reliable source that being a little bit pessimistic is also more realistic. Right. So hopefully we fall into some good, realistic things of what we're going to create and not just our daydreams of all the cloud architectures literally built on the clouds.

[00:06:34] Dave Adsit: Well, and we have talked in a previous episode about how 10x developers are enabled by 10x systems. And I've seen this solo developer work very, very hard. And I've seen this solo developer work very, very hard on building the system that will eventually deliver the features, but doesn't actually build the features now. And that's another thing that you have to watch out for if you are at this scale of solo developers. Is what I'm doing creating a business impact today or am I building for the future? Am I building the system that will enable me to release features faster later? And can the company afford for me to do that? So that's something you have to consider and you have to balance. And it's a... It can be a tricky balance. Yeah.

[00:07:22] Allan Stewart: But growth will happen one way or the other.

[00:07:25] Dave Adsit: Growth will happen.

[00:07:26] Allan Stewart: Because the business, at least every business that I've ever been part of, has an insatiable desire for more. More software. There's always some cool feature that we could be adding. And if you have investor funding, well, then that oftentimes creates growth. Just because there's this influx of money. Where the hope is that by pouring more money in, you can get more stuff done sooner and you can actually get off the ground.

[00:07:59] Dave Adsit: Well, and whether you see it or not, as an individual contributor developer on the team, there is pressure that comes with that money. Pressure to hire and accelerate. And one of the clear and obvious ways to spend investor money and create acceleration is to... Yeah. Hire more people.

[00:08:20] Allan Stewart: So as you start hiring those people, you're not alone anymore. But as long as you're in a pretty small team, you've only got a couple of developers, maybe two to four, maybe five or six even. It's still pretty small. Everybody knows what everybody else is doing. And so your impact, I think, is still pretty easy to see. Because there's not that many people contributing. And so you know what you did. Yeah. Even if you're working together as a team, it's small enough. If you're doing a pair programming or mob ensemble programming, you're still going to be able to see, hey, I worked on that. We did it. We delivered the feature. And you can see that impact pretty readily.

[00:09:07] Dave Adsit: Well, and also, it's hard to hide in such a small group. If you find that someone on the team is not contributing, everyone knows it right away. And so there's opportunity for immediately... But yeah, it's on a small team. If you have a single team at your company, everybody knows what everybody's doing. Hopefully, you are still collaborating consistently and working together on things so that you're not building those knowledge silos. You don't want to have your front-end guy, your back-end guy, and your database guy each go a different direction. You want to have people working together. But we do know what the other people are up to. Right? And when we do a deploy, everybody knows. When a new feature request comes in, everybody hears about it. It's easy to keep track of everything from a people perspective when you have a small team.

[00:10:05] Allan Stewart: I think the area that I start to see conflict in and that I start to wonder about my own impact when you're at this kind of a scale is... is picking your focus. Because it's very difficult to just do all of the work yourself, like working, focusing on just like getting stuff done, writing code, versus working on the team, working on your processes. Especially in a small company, there's not that many people. There's always that pressure to release the next feature or fix the scalability problem that was caused or whatever. And you're small enough that there's still... There's still an obvious pull towards, well, just get in there and get it done. Maybe the thing that you need to do is just sit down and write out some code. Do some refactors. Do whatever the building of feature is that needs to get done.

[00:11:04] Dave Adsit: Yeah.

[00:11:05] Allan Stewart: But if everybody is focusing on that, you know, I said I was thinking recently about lean principles. It's really easy to get into a resource efficiency mode where you're more focused on the things that you're doing. Getting done is just like the inevitable consequence of improving that system.

[00:11:48] Dave Adsit: Well, and you think about some of the related costs, if you are building features versus sourcing, recruiting, interviewing, hiring, onboarding, and training a new developer, how many features could you have built in the time it took to get somebody else up to speed where they can be productive? And who is going to be doing your interviewing? Probably your most senior, most productive developers. And so you have to balance the overall needs of the system really well in order to continue to make progress while growing the team and while training the team, right? Because a lot of times you're not going to bring in all senior developers. Some companies have that as their hiring policy. But those companies typically have big teams and deep pockets. And you probably don't if you're a very small team. You probably have a limited budget. And so you're thinking of ways to maximize that by hiring more junior developers, which means that you have to do more training with them. And of course, there's a lot of techniques that we can use to mitigate some of that, like the mob programming or the ensemble programming. Definitely, we want to be using pair programming. But also, you may just find yourself doing a lot of things. I've spent a lot of time doing code reviews and PR reviews with people who are very enthusiastic and not very skilled. And so now you're asking yourself, well, what is my impact? I'm pretty sure I've told this story before, but I have been in a situation in the past where I had a team that was international and therefore much, much, much less expensive. And we would send them work and they would work on it. And then we would bring it back and try to merge it into the code that was being worked on by the U.S. team. And then we would take, we basically spend the whole day fixing the code. And so the U.S. team wasn't delivering any new features. They were just fixing bugs and issues that were being produced by the international team. And so we eventually shut that international team down because it wasn't providing the value we wanted. It was actually costing us more to support the international team than the benefit we were getting by having them. So there's a lot of things to consider at that small team stage.

[00:14:08] Allan Stewart: Yeah, definitely. I think it's still pretty easy to see your impact because it is small. It is. But you start getting into this question of, okay, well, how do I make an impact? What's the best way to make an impact? And that just gets more and more like the clarity of what your impact is. I feel like it just goes down and down and down as things grow. Right. So you grow and now all of a sudden you've got multiple teams. So it might be a small department. You've only got two teams, three, five teams. But now there's more people. Right. And you don't necessarily interact with all of them every day.

[00:14:50] Dave Adsit: Yeah. Like your manager hopefully knows what impact you're having. Your team definitely does. There's probably a bunch of people that you haven't worked with and won't work with. And they don't know what you do. They kind of have a hint of what your team does. But they probably don't know what your skills are, what your contributions are. They don't know. They don't know if they could. If you were to contribute code to their code base, could they trust it? They don't know. And then it starts to become easy to disappear into the crowd. At this point, either for good or for ill, like you can fade into the furniture where nobody's really sure what you're doing. And this is where it starts to get really hard for people who have a strong desire to create a positive impact, which is most developers I've worked with. How do I make what I'm doing stand out so that people? See it. The easy way to stand out is just to release a bunch of code that breaks production on a regular basis. People will know your name. It'll be so famous. That's not the kind of impact most people want.

[00:15:50] Allan Stewart: You're in famous. You're inside famous.

[00:15:55] Dave Adsit: That's right. That is not the kind of impact most developers I know want to have. Thank goodness. So this is where it starts to get really hard, right? You have to start doing more. And things that I've encouraged developers. To do at this point in the scale of the of the organization is to make sure their team is delivering. Well, be a team that is constantly shipping something and promoting what you ship and people will start to know who you are. But on a more individual level, there's things like participating in group training or leading group training. You know, we I encourage my teams to do regular peer. Training and so we set apart some time every week for people to volunteer to lead a training on something they know about or are interested in. And that's immediately you're in front of the whole group, right? People are there to listen to what you have to say and they know who you are because you're the guy who talked about how to use hooks and react or you're the guy who talked about how to tune a database query or add an index to improve performance of a query. If you're doing things like that, like making yourself visible by improving the system as a whole by creating training or or doing training that levels up the group, that is a fantastic way to create an impact at that scale where it's easy to start to disappear into the sea of developers.

[00:17:28] Allan Stewart: Yeah. And I think what what occurs here is that we've already left behind the scenario of I can. Yeah. And by just getting more done as far as like the amount of work like we've already we've already tapped that out back when we were at the tiny startup that only had one developer. Maybe even in the sense you may be in the small team, you could still have more impact by just getting more done. But but we're we're really scaling. It's kind of like the horizontal scaling versus vertical scaling problem that we've seen in in compute. Right. It used to be. It was like we would scale up the database server just like you just throw more hard drives into that into that raid system or we just need to, you know, open up the case and throw in another 64 meg of RAM or something like that. Back when you were measuring it in 64 megs of RAM. Yes. Right. And so there's a limit. Like how much can that one server really do? Well, eventually you peg it. And there's nothing more that it can be done or you have reached the maximum number of slots available for adding more RAM. And so vertical scaling is hard. And so you go to horizontal scaling and you say, oh, well, let's just have more database servers or more application servers. And so now it's kind of the same problem. It's a similar scaling problem. But now we're talking about people and how much time each individual person is. And so your ability to impact the system as a whole is going to depend on your ability to impact other people. What are you doing that makes everybody else better? Right. What makes the system better? Those are the things that cause greater impact for the system.

[00:19:29] Dave Adsit: Well, we've talked in the past about heroes. Right. And how neither of us is a big fan of having heroes in the workplace. Right. Right. Because usually the person who comes in and saves the day by fixing the error in production is actually the person who wrote the code that caused the error in production in the first place. Yeah. And so celebrating, I mean, not that you shouldn't celebrate correcting a problem, but celebrating creating a problem and then resolving it seems a little bit odd, or at least the way I've seen it implemented.

[00:20:02] Allan Stewart: Heroes are flashy, but let's face it. Tony Stark is a hot mess. Correct.

[00:20:08] Dave Adsit: Yeah. I was going to say, in addition to the hero mentality that we want to avoid, where we don't want to have to have heroes to solve the problems in production, it's usually really hard to become that person unless you have been with the company for a very long time. Right. Yeah. And if you come in as a new developer, you're not going to know all the weird DNS stuff that was done 10 years ago to make this one service work right. Yeah. Yeah. Yeah. shouldn't because we just kind of hacked some stuff together and we have too many layers of routing. And the way we overcome too many layers of routing is by doing a bunch of redirects. And you know, there's, there's weird stuff that happens in a system as it grows, a technical system as it grows. And, and somebody who's been around for the duration may have some knowledge that nobody else has. And it's going to be really hard for you to get it. And it's going to be really hard for you to create the same kind of impact as the guy who's been here for 10 years. Yeah, definitely. And, and so let's come up with other ways to create impact, positive impact in the system. So even beyond that, you can get to a large department, right? Where you have lots of teams, lots of managers, lots of directors, lots of products, oftentimes to lots of products, a whole suite of products, or even multiple portfolios of products. I think the biggest department I've worked in was 3,000. Engineers. I didn't even know all of the people on my 30 person team. Not really. Like I saw them in meetings sometimes, but we never interacted. We worked on a collection of products that were somewhat related, at least at some level of abstraction, but we never saw each other's code. We never reviewed each other's code. We never sat with each other. We never talked to each other and we never went to lunch together. It was just, we saw each other in quarterly meetings and that was about it. Yeah. And that was on my team inside of a much, much larger organization. And so how to create an impact at that scale, it becomes very challenging. You're, you kind of become a number. Your team might actually just be a number, right? And so you, but why, but why do we get to that scale? Why do we do that? Right? If, if people individually feel demotivated by not creating an impact at that scale, why do we do it? And there's a lot of reasons. And one of them is, is that we want to create redundancy. We want to create safety in the organization. Honestly, a large enterprise is doing everything it can to prevent a single person from becoming impactful either for good or ill, right? It's a self-defense mechanism for a large company is that it is slow moving and hard to, it's hard to improve, but it's also hard to break.

[00:23:00] Allan Stewart: Yeah. It's an interesting defense mechanism because that's where disruption becomes such a problem. Right. Because an organization like that, you know, large organizations, they don't, they don't deal well, deal well with change because change introduces risk and risk can go good or bad, but we're kind of risk averse. Yeah. Because, because of so many bad, bad things that have happened, right? That's why you're, that's why your policies in the big company are the way that they are is because at some point, some people took advantage. And well, we had to nail that, that down and make sure that nobody takes too many sick days or whatever it is.

[00:23:43] Dave Adsit: Right. So the, those large organizations, they drive for a form of homeostasis, right? Where they're just kind of stable. And every once in a while, you'll have an opportunity to join the, the internal startup or the, what do they call them? The, the disruptor group, where we're going to disrupt ourselves and create our own, the lab, I think often they're called the lab, right? We're going to create a lab and in the lab, we're going to break all the rules and we're going to do exciting stuff. And then if it works, we will introduce it into the main product line. And if it doesn't work well, we didn't put the main product line at risk. So there's possibilities even at those scales, but but it is increasingly harder to do. And so that at that point, you start looking for other ways to have impact besides being an individual contributor, right? And, and so you start looking at career paths. But before we talk about career paths, like I wanted to talk about like just different axes of scale. We've talked quite a bit about the number of people in your organization or specifically your engineering organization. But another thing that impacts your ability to have an impact is the phase of business. And so if you think about three broad categories, you've got your startups, your scale ups, and your enterprise, the things that are valued at each of those scales of business are different. So when you are in your startup phase, things that are valued are taking initiative, getting things done, delivery, delivery, delivery, delivery. And things that aren't valued very much are following the rules or being overly cautious. Because as a startup, you're burning capital quickly trying to find a market find customers, whatever, because the business is trying to do the same thing that you personally are, the business that you are in is trying to have an impact in the broader market for your services, right? And you do that by differentiating by being faster by being whatever flashier, you aren't going to be bigger, you're not going to be more stable, you're going to have a hard time landing enterprise contracts when you're a team of five. But this so the startup has certain things that it values. Yeah. And the funny thing about it is that we often set our company values based on our startup phase. But then they have to change when we are in our enterprise phase, because enterprises value very different things. Enterprises value following the rules, not having a huge impact, slowing down a little bit to reduce risk, being more stable, less erratic, right? Yeah. And in between, there's the scale up phase where we've started to find our product market fit, starting to do more of what we do. And in that phase, the thing that we value is people who can come in and help us tame the West, right? We were the Wild West, we want to tame the West, and then we want to eventually become cities. So in our scale up phase, we value people who can take an area and homestead it and bring it under control and clean up all the code that we created that was garbage when we were a startup. We never bothered to clean up because we were too busy moving fast. Every scale up I've ever been part of has had that. I'm not convinced you can survive your startup phase with clean code. People have told me that it's possible, but I don't know anybody who's done it. Every scale up I know has a mountain of bad code that they wrote in a hurry so that they could find a market. And then you have to clean up the messes you've got. And that's a different, it's a different skillset and a different value and a different way to have impact than either in the startup. Or later in the enterprise phase.

[00:27:38] Allan Stewart: Yeah. Yeah. I really like what Simon Wardley of Wardley Map fame says about this kind of concept. He groups it up in three categories. He calls them pioneers, settlers, and town planners, right? So when you're in that startup phase, and startup doesn't necessarily have to mean that the whole company is a startup, right? But you're in that phase, right? Because we're not talking necessarily about the size of the organization now. It could be, you know, you're in that phase, it could be that you, you know, you're sent to work on, you know, that lab team that you were talking about or something else, but, but you're in this mode of exploration. We're going to see what's out there and see what's possible. We don't know what's, what's just over the ridge. We're going to build on this new thing. You know, now that, now that you can get an AI from cloud provider, well, let's just see what we can do with it. And so you go and experiment.

[00:28:35] Dave Adsit: AI into our spreadsheet. Our spreadsheets and our accounting software, because that's where we need it.

[00:28:39] Allan Stewart: Yeah. You just gotta, you gotta try everything.

[00:28:41] Dave Adsit: Predict the next number, AI.

[00:28:44] Allan Stewart: And so you go out there and that's a different set of skills than is needed for the settlers, right? The settlers don't want things to be quite so wild because now you're in that product phase where you, where you, it's no longer acceptable for 50% failure rate, which was fine when you were experimenting. And so you're like, oh, we didn't even know this was possible before. And the fact that it works sometimes is amazing. But now that now you're trying to sell it as a product, people are unhappy if it doesn't, if it doesn't work. And so like, you're starting to get into this phase of, well, we gotta, we gotta settle this down. Let's, let's plan out some, some roads and like, where are we going to put things in, in the settlement? And then it just, it increases from there. You get to the town planner phase where you've got people, you know, laying out going to be, and whether that, you know, whether the sewage system is going to be able to work and how are we going to get power to all the buildings. And by the way, some of those buildings are skyscrapers and, and you're in this, you've evolved into the commodity space. As far as the Wardley map is concerned, it's like, oh, well, there is no more experimentation. We're not trying to do something new. We're trying to do everything according to the specifications. And that's a very different skill from those other two groups. Just, just as you mentioned.

[00:30:06] Dave Adsit: Right. And you have to be aware of them because the way that you have impact is going to be determined by what phase this business is in. If you are behaving like a town planner in the startup phase, you're never going to get anything done. Nobody's going to be very happy with your performance because you're, it doesn't look like you're getting the work done the way that it needs to be done at this phase. Likewise, if you are one of these pioneers who's just like blazing trails across other, across whatever exists and throwing out code that breaks half the time. And, and I'm not talking about you run an experiment and the experiment, and the experiment fails half the time, because that's learning. I'm talking like 50% of the HTTP requests come back with a 500. People are going to be very unhappy with you in that town planner phase, that enterprise phase. We want to make sure that the requests are handled. We want to, you know, do a certain survey and make sure we've provisioned enough web servers to meet the load. Cause we're going to, the day we turn this on a hundred thousand people are going to start using this product. And we've seen failures in all of these, right? Startups fail all the time. You don't even have to mention startups fail. Probably everybody listening to this podcast has participated in multiple startups that have failed. I've started a few that have failed, but also we see enterprises fail, right? A few years ago, we in the U S launched the the health insurance marketplace for the whole country. And it was a huge audacious project and so much money went into it and it didn't work on day one. And there were tons of town planners there, but it was just so hard to get the load, right? Yeah. Well, and I, or to plan for the load, to plan for the scale that was necessary. And the same thing happened in, I believe it was Switzerland when they launched their, their national healthcare system. It is very hard to get those things right at scale. And you certainly don't want somebody who's coming in here, like it's the wild west and they could do whatever they want. And they've thrown up one server that runs a database and the backend and the web and everything all on one server. Like we used to do 20 years ago in startups, right? Right. You just buy one server and you run all of the software on it because buying a second server was too expensive. Yeah. Right. We just, we have to, we have to do things differently based on not just number of people, but also phase of business.

[00:32:40] Allan Stewart: Right. Right. So I think about your ability to create impact then depends a little bit on where you fall in that spectrum and what you're, what you're able to do, right? So if you're in the, if you're in the company that is more commoditized and they, you know, most of them are town planners, but you yourself are more of a pioneer. That doesn't mean you can't provide impact. You just have to be careful about how you're going to do it. And I think that's a really you might, you might find that that exploration that just kind of comes natural to you. You can find ways to build upon, right? This is like the Google 20% time ideas. Like, yeah, go experiment, try some things because you can build on everything that we provide the, this infrastructure at Google in order to create something new. If you're, if you're just going to go off and do something It's very hard to get any traction. So you might be able to create impact in those scenarios, if that's what you're good at, and you can demonstrate where this provides value and how are we going to create a path from here to there or, or vice versa, right? So if you are more of a settler or town planner, and you're coming into a company that is experimenting, you might be able to show value in ways that you can standardize some of that code. Make it so that you can actually launch the product and half the requests aren't failing, that they're, that the product works. So it just depends on your ability to kind of read the room of what is needed and how you can provide value for what they're looking for.

[00:34:28] Dave Adsit: Well, and it can be hard for us to make that transition. There's the concept of the technology, adoption curve. And I know myself from many years of working in tech, I am on the, the right side of the chasm staring over at what's coming. I'm not the early adopter of innovator. I am at the very beginning of the early majority. I want to see if it's going to, if it's going to survive the chasm crossing before I want to adopt the new tech. But if you are one one of these people who's far out on the end as an innovator or an early, early adopter, you're going to want to work in a different type of company in a different phase or find a role within a scale up or an enterprise that allows you to do that work productively and have that positive impact. And those can actually be super, super impactful roles for people who find them because an enterprise, I mean, what is the word we use? Stodgy. They're slow. They don't, they're slow, they're rigid, whatever. If you're the guy who's saying, hey, we could improve database performance by 20% by implementing this new queuing tech or this new query technology. I mean, you could be a hero to all of those people by being that innovator, early adopter, because a lot of people in enterprises are going to be more like me, early majority or late majority, or even your laggards, right?

[00:36:02] Allan Stewart: Just be careful about being a hero.

[00:36:05] Dave Adsit: Just be careful about being a hero. Don't break, don't start a fire so you can put it out. Don't break somebody's leg so you can splint it.

[00:36:13] Allan Stewart: Right. Exactly. So as a precursor to career paths, I think impact can also be increased based on what we sometimes call is your shape. People talk about T-shaped people, V-shaped people, paint drip people. And this is, these are different words. These are different words to describe how an individual may have multiple different skills, but they're not equally good at every skill. So you might be really good at writing code. So we, we talk about, you know, the kind of a depth, right? This is a breadth and depth question. If you're, if you're very shallow in all of your things, that's not terribly useful. You might be able to help in a lot of situations, but you can't do very much in them. If you're really deep in once in only one skill, then that's the only thing that you can do, right? If you are the Java developer who works on API backends and you don't do databases, you don't write SQL, you don't know anything about deployment pipelines. You don't write JavaScript on the front end. Well, you don't write mobile. Then these you're limited in what you can provide. Right. You're the business. And so, you know, I really like the, the T shape or V shape concept. It's like, Oh, there are multiple adjacencies that you're good at. And, and you try to broaden out those things, but you don't go so broad that you're just completely shallow.

[00:37:50] Dave Adsit: Right. This is one of the very first things that I reach for when I'm coaching someone is let's find an area that you're interested in so that you can go deep on this area while maintaining the breadth that your team needs for you to deliver. Right. On your day-to-day work. Um, and it's usually pretty easy to pick out like, Hey, you're working on a team that is delivering a web project, but only two people on your team really seem to have much depth in CSS. So if you become one of the three people who have depth in CSS, you can really have a positive impact on how good the user experience is the user interfaces for this part of the product. Or again, this one is kind of surprising to me because it seemed like For the first five to seven years of my career was databases, but a lot of people, a lot of modern developers don't know a ton about relational databases or, or document databases or when to choose one over the other or how to tune a query in either of them. And learning about database tech is a great way to get deep. Um, I have a friend who always says the problem is DNS, even if the problem is not DNS, it's still DNS. And, and he's right. Like if you ever work on anything networking related, it's always DNS. Um, and developers don't typically understand it very well. And your ops people who understand DNS better don't understand code as well. And so you need to have some breadth across both of those things, but then

[00:39:19] Allan Stewart: find an area to go deep in. Yeah. Yeah. Going deeper on something that you're already good at can make you more of an expert or you find something that is needed and build up some additional depth, right? So like you're, you're spreading yourself out and those don't always have to be technical things. In fact, in order to make a bigger impact, oftentimes it's non-technical ways that you can improve, um, you know, building up those systems, figuring out how can you, how can you influence members of your team in a more, uh, in a more effective way? Uh, so you might be reaching for soft skills. You might be reaching for communication. Skills that help you explain why are we doing things in a particular way? And you find yourself working less and less on, you know, code or delivering features, but you can impact people by helping them understand how do these features fit into the whole, what does this system architecture, you know, what, what is this going to look like at the end, right? Instead of having an accidental architecture, that's just, well, you didn't know we were just building features. And we're just kind of piling more and more stuff on, well, maybe you go intentional about it and say, Hey, how is this going to scale as we increase, you know, architecture wise, or how can we help our people scale, um, manager wise, which kind of leads us right into that question of career paths.

[00:40:53] Dave Adsit: Right. And there's, there's typically broad strokes, three career paths for your software developer, right? You, you go, as you start developing your skills, you start to learn what you're most interested in. And it can be, you can either stay on the individual contributor path. You can go very deep as basically like a principal type engineer who writes code on a team all the time and really understands the toolkit that we use here and how to deliver software here. You can also go into the manager track, which is pretty obvious, right now you're managing people. You're helping facilitate other people having a positive impact and develop their careers and develop themselves so that they're having a positive impact. You're also helping to, projects and things like that. But then like your third path is your architect path where you are still very technical, but you are looking at the system as a whole instead of individual parts of that system. And each of these is a way to have a very strong impact on a team and on an organization and on a socio-technical system. Um, I've tried all three. I have fun, all three. I wouldn't say that any of them is less valuable or less interesting than the others. It just depends on what you're most interested in at the time and, um, what skills you're willing to develop. If you don't want to develop the skills of being a, of doing a good one-on-one or leading a retrospective, then I would recommend that you probably not take the manager path. You're going to have a hard time in that manager path. If you don't want to develop the skills required to do the job, well, if you're obsessed about the, the code and the patterns and whatever within a system, within a single code base, the architecture path might not be the right fit for you. But if you're interested in how do multiple pieces play together and how do these five, six, 12, 53 teams work on a system together without getting in each other's way, then you should probably pursue the architect path. It can be a lot of fun. I know that you and I have both had fun doing the architect role.

[00:43:03] Allan Stewart: Yeah, that's definitely where for me personally, I gravitate every time I go through, I like the individual contributor part. There are aspects of, of a manager role that I like. There are some aspects that I don't like as much. Um, but, but architecture is definitely something that just kind of I'm drawn to, but I think, I think the important thing to note here is that there is a lot of overlap between them. Right. Like to be a good architect, you have to have a lot of the same kinds of people skills that a good manager has. It's just, you're kind of employing them in a different, in a slightly different way. Your focus is a little bit different, right? There's the, the more technical focus versus the people focus. But since it's a socio-technical system, both are needed and both need to be able to reach over and affect the other at times in order to do their jobs really well. And I feel like a lot of that stems out of knowledge of that individual contributor path. So how you're giving impact and what the career ladder of your company looks like might be different. Uh, a lot of companies kind of stall out on the individual contributor path or track, and you kind of have to decide which fork in the road you're going to go. But that, but that is separate. Like if you're just thinking about like career progression from like a titles and compensations standpoint. It's it's important to note that that that is different than impact. Although if you are showing yourself with high impact, then, you know, businesses tend to want to reward those people who are making a difference.

[00:44:49] Dave Adsit: Right. Well, and I would say if we were to summarize the three career paths that you can take, um, you're going to create the most impact as an individual contributor by delivering within the people on the tooling that you're using there. If you're talking about a manager, managers make a big impact by enabling teams to deliver. And that can mean training people, career development for your staff. That can mean a lot of different things around how the teams interact. But as a manager, you should be judged on, your impact should be judged on how well the teams you manage are delivering and the overall impact they're having, which again, relies on the individual contributors to be having an impact and delivering within the team. And then as an architect, the way that you have the biggest impact is by setting up the system so that everyone could succeed. What aspects of a socio-technical system allow people and teams to succeed within the system? If I, I mean, I could get into specific details, but like if I introduce rules for intergate engagement between teams, Hey, when you work, when you integrate two different products, you always use an API and the API can include a queue. And this is the queue we use at the architect, at the system level. And here's how you interact with it. Great. If I, as an architect, try to micromanage into a team, I'm going to have an impact, but it's going to be a negative impact. I want to, and honestly, one of the things that you're going to be judged on in how well you can influence people who don't report to you to deliver within a system that will

[00:46:36] Allan Stewart: create a positive impact for everyone. Right. And because you're on that technical side of the fence is the technical, you know, what we're delivering with all of these servers and code and databases, like, is it fit for purpose for the business? Right. Because there are many That doesn't necessarily mean that you, that any one of them is a good fit, right? So microservices are a big rage these days. Great. Microservices are really good to solve certain problems. Are those the problems that your business has? If not, it might not be the right architecture.

[00:47:18] Dave Adsit: Right. Well, and I would say you're hitting on something there that I think we've kind of overlooked so far to some extent is that for you to have an impact, you need to understand the business you're operating. And what the needs of that business are. And for almost every technical role, the needs are include delivery, but also prioritization and what are we delivering? And so I think it's really important for us to understand the business we're working in. We are professionals after all, and understand what the needs are, whether you're an individual contributor, a manager, or a, an architect, and regardless of the scale of the business. As we've discussed, the needs of a business change, whether they're a startup, a scale-up, or an enterprise. And so if we can understand what the needs of the business are today, and in the near future, then we can lean into doing the things that will have an impact where we are. I think one of the things we need to be aware of and avoid as an engineer is over-planning too far in the future when that's not necessary for where we're at as a business. And in the future,

[00:48:30] Allan Stewart: Agreed. And I like that when we're looking at ways that we can increase our impact, being intentional about looking around and saying, okay, well, what are those needs? And how can I fulfill a need that is currently underserved or not being fulfilled? And ultimately, I guess that's kind of the whole concept behind impact. There. In order to make an impact, I need to deliver value. And if I want to make more value, then I need to find somewhere where we're not delivering value and make it better.