Understanding team priorities and career growth

It takes more than wondering about Disney Plus's database schema while watching Frozen to be a great engineer. This is episode 4 58 of the Soft Skills Engineering Podcast, where I am your host, Seamus and Dance. I'm your host, Dave Smith. Soft Skills Engineering is a weekly advice show about all of the non-technical things that go into the technical field of software development, like trying to type in a SQL injection in on your TV re mote. Right. And the search bar of the Disney Plus search bar. Vivo or whatever yeah whatever app you're using. Close quote dash dash. Turn off ads, semicolon. Yes. Type that into your smart TV. Turns out there's a stored procedure in MySQL. Yeah. Well, do you want to thank our patrons? I do. Here we go. This is the list. This is the list of the people who type things into their Patreon profile name field that makes me laugh every single week. Here we go. They are croissant, connoisseur. I only learned to code so I could look cool in public, but now I get excited about cleaning up legacy code. Please send help. Noah Lab Hart, my dad jokes cron job is almost done. I just need to completely rewrite it in this hot new programming language. A really expensive tube. Nice. Alexander Kuznetsov, Nick Molynew, attribute error none type object has no attribute two string. Javier Gonzalez, Chewy, Ted Timbrel, I like a dude chacha. Whoosh with a crying face emoji. Become a senior engineer dot com is a newsletter you should read. Doing my part to make Dave's heart swell, but he should probably get that checked. Yes. Dan from Drone Deploy, Chase W. Norton, never is not just a creator on Mars, Llamingo Emoji. I like chicken, I like liver, meow mix, meam meicows, mi plexase deliver trash panda. Get status, Kyle Boss, can't see Dodds. That guy over there. Nevar is not just a planet in the Vulcan system. Jenny Kim, the stochastic parrot. Helicone.ai, best observability tool for AI. Red Panda is best panda. How much wood could a much woe wood could a wood chuck could? Jonathan Kings and I, beautiful functional user documentation. I'm your host Stephen Colbert. William Angel.net, I'm now rehiring personal data salespeople because the AI productivity bump was a fat . Entry level, six years XP. Ragnar, Braden Keynes, John Grant, Brittany Ellick come to the slash new conference in Newcastle, Australia, May 28th and 29th. Mate. Just kidding, the mate part. I added that. If it looks like a duck, swims like a duck and quacks like a duck, then it's probably a soft skills engineering listener. And lastly, ouch my 401k. There you have it. You had a good run, four oh one K. It's nice knowing ya . Yep . Wish I could have spent ya. It sure was nice sending chunks of money into this thing and watching it go up and knowing someday I'll be useful and then not having it be useful. Just wait for your fifty-ninth and a half birthday. Yeah. I think you should use the time value of money to argue why you should just not save for retirement and spend, spend, spend. Because it'll make you so much happier now to have that cool impractical motorcycle than if you're sixty and you have an order of magnitude more dollars. Yeah what what you need is a T V that's just a few inches bigger in the diagonal. That will do it. That will finally make you happy. Yep. All right. I'm gonna le read our first question from a listener named Nico who says: nearly every time certain developers on the team want to address technical debt, they just end up adding more technical debt. Of course, after one round of addressing technical debt, the developers in question believe in yet another round of redesigning and refactoring. This stresses me out for many reasons, as you can imagine, and has led to my productivity dropping to an abysmal rate. I spend a large chunk of my time resolving merge conflicts and reorienting myself in an ever-changing code base. Do you have any suggestions for me? Ha Oh, the tech debt spawn. Yeah. This is a whole new layer on the problem of convincing the business that it's worth investing in technical debt is you have to convince them that you're correct in your assessment that this thing is actually bad and causing you problems and is worth the time invested to make it better. And then you have to hope that the thing you do to change it actually makes it better. It's like if you paid off your credit card and it turns out that you paid them negative dollars somehow, but you didn't get the money, but now your credit card bill is larger. Like, wait, you can you can like mess up paying this debt off? Yeah. You can pay it off in a way that makes it larger. That's right, technical debt. And you still don't have the money? The only kind of debt you can pay down and it goes up. Yeah. Dave Ramsey doesn't know what to do about that one now. Exactly. When you pay technical debt, it's more like Dungeons and Dragons when you roll a die. And it's like every time you pay it, you're actually rolling, and there's really a chance you might just get hurt. Yeah. There's also this effect where you don't know if paying down the technical debt is actually paying it down for like six months . Yeah. When you're less familiar with the code and more developers have had a chance to read it. And then you go, okay, this was good or bad. You have the sword of technical debt slang, which is a D twenty minus fifteen. That's how much technical debt you remove. D twenty minus fifteen. Is that like a one in four ch a w a three out of four chance that you're going negative. You're gonna have even more technical . Yep . But maybe. Maybe one in four chance you get better. Yeah. And then I guess I guess you gotta add in your like experience modifier to the okay. Um this metaphor has been stretched. It's been stretched to the D20 . I gotta say when I when I am contemplating approving technical debt projects, the ones that are really appealing to me are when a developer says, we can delete this service, or we can delete a database, or we can delete thousands of lines of code because we found a different way to do it. Then I'm like, okay, that's the kind of debt that usually when you pay it it goes down. Yeah. But when they're like, we just want to rearrange this code, but not really change it. Not change the way that it's that it works from as viewed from the outside. I'm like, I don't know. We feel like we messed up with our last abstraction because there are all these cases that don't fit into it. But good news, we have a new grand unified abstraction that will bring in these new use cases and then cover every use case and never need changing. And we're going to keep the old abstraction just but you know for backward compatibility. We're going to layer yeah we will layer on a new abstraction that will cover the old one and these new things. While still exposing the old abstraction because there's people that are directly using it. We can't can't just delete it. Yeah. And and they won't migrate to the new one yet. Yeah. Large chunks of my time resolving merge conflicts. That one Yep. That's a very concrete thing you can bring up and say, Hey, this is costing me time. I know you have ideas of the benefit of this, but this is a very explicit visible cost of the time that I lose to merge conflict resolution for things that do not make the business any more money. And I think that's a legitimate concern and a thing you should if you're if you're proposing technical debt changes and have a bunch of ideas on how to fix it, like not messing up people who are doing work is uh certainly one of the things you should think about. For sure. And when when you say merge conflicts, I just know this these are giant refactor projects. And when they say tech debt, what they really mean is refactor. Yeah. Yeah. I think it's worth bringing up to to the team and saying, Hey, how do we not break work in progress when we're doing this? Yeah. Maybe you have to wait. Maybe you have to have a synchronization point. Maybe like don't tackle it if you know somebody's working on a thing. Maybe you have to go back to subversion and you just have the lock on those files, and so they cannot do any refactoring. Microsoft Visual Source Safe. Yeah. This this file is checked out by me. Yep . Git was a mistake. It's too easy. It's too easy to let people change things. Yeah. I'm reading this from the perspective of someone who's not a leader on this team, just an influencer or a peer. When you said influencer, I imagine doing the flossing dance from Fortnite on your internal TikTok that of course your company had to recre We need ways for an employees to engage with each other around our company values and brand . Droans . We'll have to send self st selfie camera or like little tripod mounts for your phones. Yeah. Uh to every employee so they can record these things in full frame. Yeah. What up gang here at the daily stand-up? Oh boy. I don't even know what I was gonna say, but if something about trying to influence this team, you you find yourself in a frustrating position because you can clearly see this problem, but you're not in the approval process for saying, yes, we're going to work on this or no. And I gotta tell you, when I look at this team, I think, okay, where is the product manager who are notorious for denying tech debt job s like this. I don't know. Do you have a product manager on this team? Yeah, usually you are trying to battle against the structural impediments to getting these things approved. Maybe the manager is not technical or the person with the approval is not technical or or convinced by the smooth words. But it sounds like the people working on it are really pumped and and uh and feel like it's going great. You know? Yeah. It worked so well last time. Let's do it again. Yeah. And and it sounds like they enjoy doing this thing. So on your team with the developers you are pushing against some tricky forces, but the default answer for from a business for can we do this thing that doesn't make us any money is no. Right. So are you suggesting you you need to like summon the eye of Sauron of like, hey, we're doing a bunch of stuff that doesn't make us money that you know how developers always say words you don't understand that sound really important . It's it's it's got this tangible negative thing and not making us money. Yeah. This uh monoid endofunctor rewrite is actually not good. Yeah. You mentioned Jameson that you've got these high energy developers who are really interested in doing this. And you could help them channel that energy to something productive. I mean, may maybe these are the kind of people that only like to work on tech debt. Okay, so be it. Let's find a way for them to delete a legacy system and transition its use cases off to a modern replacement. You know, something like that. Or let's find ways for them to reduce your hosting cost bill by reworking things or deleting unnecessary stuff. Like let's have them do something tangibly beneficial to the team or business rather than just kind of rearranging the letters in your code base so that you have to resolve merge conflicts and remember where a file is because it's changed location. Yeah. I don't remember the information about how big this company is that the person works at. I'm assuming it's a fairly large company, but even if it's a small company, code bases have layers, and for every refactor, there's some place where you can't quite fix it off and and code bases develop inconsistencies over time and and there's often efforts to kind of standardize and make everything work the same way and maybe that's some of what these refactors are doing. But your your question mentions how do I orient myself in an ever-changing code base? And that to me feels like these are these are new patterns that are being added that don't apply in other places. Yeah. And I think that's a valid concern to bring up of hey, consistency is worth something. I am often the argument the arguer for inconsistency at my current job, so I'm being slightly hypocritical. But you can kind of argue against doing this, saying, Hey, I I know you think this way is better, but it's now gonna be harder to understand because we will have two ways of doing it. Yeah. And the global cost to the code base of adding more inconsistency is real and maybe not a thing you consider. It is real. And think about a developer who's not familiar with the full event history of the full timeline of all the changes that have been made over the years. They come in and they're they're pattern matching off of some old legacy code that they don't know is old in legacy and they build a feature that way and then during code review you go you have to go, Oh, sorry, you're gonna have to rewrite this because you chose to pattern match off of an old file that no longer has the modern patterns that we want to build with. Yeah. That's a real cost. You know, that significantly increases the time to delivery on a feature. Yeah. I'll take a counterpoint here, Jameson, which is that it's possible that the question asker is actually a curmudgeon. And I don't know if that's the case here, but it's possible that some of these tech debt things are actually net positive things. They're they're good. They make the developers more effective. They are less error prone. They are higher performance. I don't know what they are, but there might actually be compelling reasons for some of these things. And you are that team member who's like, well, I just don't like it that you change things. You moved my cheese. Yeah. How would you how would you know if you are that person? I mean, are there are there changes you feel like have been useful or improvements that you see that could help? Is it is it any change is bad, then yeah, that's a pretty yeah. Pretty strong signal that you need to accept some change is potentially good. I mean there's a lot of merge conflicts that you end up having to deal with. That's one thing. But sometimes merge conflicts happen because you just haven't stayed up to date. It's like, well, I haven't merged from the mainline branch in like four weeks and now I have a bunch of merge conflicts and it's like yeah uh that does tend to happen if you don't stay up to speed. Yeah. I don't know. I guess there's a bunch of different workflows but a four-week old branch sounds like a nightmare to me. Yeah it sounds like another problem. Maybe this is an experienced engineer who's been here a while and so they just really know their way around too. I could see that being frustrating. They got a bunch of muscle memory. Yeah, and often newer engineers to the code base come in and of course when you see code that you did not write, what do you do? You say, Hey, this is all wrong and garbage and must be rewritten to be correct, which just so happens to end up aligning with how I would write it. Right. And if you have spent the time to understand why it works the way it does, then that is gonna yeah, you're you're losing knowledge that you've worked hard to build up and gonna have to redevelop it. So I I could see the concern around that. I just know that I I've been part of teams before where as a team we agreed that there was a better pattern and we had really compelling reasons, or at least c reasons that seemed compelling to me at the time, and and even looking back were compelling. But there was one developer I remember who'd be like, oh, I just can't get this task done because you guys keep moving my cheese. Like I every time I try to commit, it's like there's this yeah. Change that I have to merge or you guys have changed the permissions model, so now I can't, you know, the the code I wrote doesn't work anymore. I'm like, yeah, I get it. There sometimes there is a cost, let's call it a a collateral damage cost to doing something that in the long run is going to be a good thing. And it's like, yeah, it's unfortunate. And I wonder if maybe this this uh question ask just happens to be that collateral damage this time, or if indeed these are just bad tech debt refactors. Yeah. My most concrete ideas are I think it's fair to say, hey, do this in a way that doesn't break my work or or if it is going to tell me ahead of time. Let's work it out so I don't just get surprised. Exactly. I think that covers the ever changing code base stuff too. Don't just drop in a brand new abstraction that changes a the way a bunch of things work. Tell me. Tell the team so that they know to use it. They can get feedback on it. And it might mean spending more time talking about it and less time doing it, which I think is probably okay. It probably tempers the uh the frantic pace at which this is moving in maybe a direction you don't love. Hopefully it improves the direction and gives more time to make it a smoother change instead of just abrupt. Yeah. I think if you approach tech debt like a backward compatible API change migration process, A, you're gonna be a lot less likely to do it because there's a lot of work that goes into that. Yeah. And and B, your team will really appreciate the work that you put in to A inform them. Oh boy, I just did nested A. I said A and B and then I did a this is Roman numeral one. Exactly. Roman numeral one inform them. Yes . Be uh nested Roman numeral one. Uh inform them that about the change that's coming and and give like give chance for for them to give feedback. And Roman numeral two. I can't remember what I was gonna say for two, but I had to do Roman second Roman numeral or Yeah. And you do. Now you do. Now I do. Might may or may not be cohesive with the first thing, but whatever. Fair enough. All right. All right. Dave do, you want to read our next question? Yeah. This comes from an anonymous listener who says Hi, I'm software engineer at a big tech company, and I'm starting to feel siloed in my individual contributor role. I'm getting my work done, but I'm often lost when it comes to the bigger picture. I can't keep up with what our internal customer teams are doing, what they need, or even what my own team's priorities are. I'm feeling siloed and it's starting to worry me. I know that just being a good IC isn't good enough to advance my career here. To get promoted I, need to understand the impact of my work, be aligned with the team and customer goals, and show that I can contribute to the overall success of the company. But how can I do it? How do I stay informed about customer needs and team priorities and position myself for career growth The pressure's on. Were you saying my precious as in Gollum? Yeah, they just came in rings. That was unintentional. I think it is for Gollum too. Seems like a verbal tick for him. Yeah. This is a good question. I think good news because usually people are happy when engineers want to raise their heads up and get more context and contribute more to the vision and direction. I feel like generally leaders, managers would prefer if their engineers cared more about this kind of thing and are trying to make them care more about it or or bring them that context. So just the fact that you want to do it is useful. I don't think this is a thing you're gonna have to like wade through a ton of red tape to do. I think if you if you raise your hand and say, hey, I want to talk to our customers more, people will be like, Great, awesome. There's probably a point in which you could do it too much and there's someone might worry, well, how are you gonna have time to get your work done? But if you're doing none of it right now, I think it should be you should be swimming downstream to say, Hey, I would like more context. Can I talk with our product person or the customers more or be in some meetings or hear more about the direction or whatever? Was that your experience at a big tech company? Like were people like excited when you expressed that kind of desire? So I was managing a bunch of teams, but I think yes, I think for the individual contributors, yeah, if there were like cross cutting projects or or things like that, then I guess it was just me. I didn't really see it happen with other people that much. No, no, I'm saying it it was usually folks that I worked with saying, Hey, I care about this other thing and then me kind of yeah shuffling them in to get more context about it. Yeah. That makes sense. I think what you're gonna say is that is not your experience though. Yeah I was I was a I was a little bit adversarial on that because when I worked for a big tech company, I actually found it to be a ton of work to try to do this. It's not like there's one org chart for a one million or person organization, you know, like that just doesn't didn't exist. And there's also not a custom er team relationship chart where it would trace out all the dependencies and all the dependes. Like if my team served seventy-three other teams, there was no one place I could go to find that list, typically. Yeah. And it was just a lot of work. Like just figure I don't know maybe it was because I was in a hyper growing organization, but virtually no one I talked to could give useful information about who did what or what team served whom. And I remember once in a while I would stumble upon someone who actually knew what they were talking about and I'm like, oh man, I am going to latch onto this person. They're gonna get so sick of me, all the questions I'm gonna have. So it was hard. Like it it took effort. Okay. I think I get what you're saying. You're you're saying it was not easy to disc over this information. Yeah, like if I and if I asked my manager, hey, I want to get more involved with what the rest of the teams are doing and have more influence in the organization, my manager would be like, that's awesome. And I'd be like, how do I do it? And they'd be like, I have no idea. Yeah. Go figure it out. Okay. It would come right back to me. Okay. I think I was just talking about I wasn't thinking about that aspect of it. I was just thinking about kind of like someone saying, no, don't just put your head down and do your tickets right like people people aren't gonna say that but that's a good point that yeah well how do you do it is is hard. Yeah, you're right. Like everyone everyone likes it. Right. Like everyone likes to have a team member or or someone who reports to them have this attitude . But it is hard to accomplish, I think. So I don't know what our internal customer teams are doing. It sounds like you at least know who your internal customer teams are. So ask 'em what they're doing. Yeah. And does that feel weird, you know? Because sometimes you go, all right, I'm gonna set up a meeting with their team lead and just ask them what they're doing. And their team lead is gonna be like, what is the purpose of this meeting? I already talked to your team lead. You know, like what's this for? I don't know. I'm just suddenly I have all this naysaying because I just remember so much organizational friction working in a big tech company like this. Just trying to get people's attention took so much work. Well, if they say that, then great. Go talk to your team lead about what their team does then. I know, right? You're you're you're right. Of course you're right, Jameson. Like you should you shouldn't let any shouldn't let any of my naysaying slow you down from doing these things. Because you have to risk being seen as obnoxious or nosy or out of your lane in order to be impactful. Like it these two things just come hand in hand. Yeah. You never you never change what you are doing and make a bigger impact without affecting someone else. And if you do it enough then someone else is going to think that effect on them is annoying or bad or whatever but that's fine. Yeah totally and you just have to be okay with that. Yeah. Maybe they'll say no, I cannot meet with you. All right . At least now I know. Show me your like wiki page or I don't know. Yeah, exactly. Guarant guaranteed they have a wiki. I don't know why, but every tech company, every team at every big tech company has one of these things. Yeah. I actually enjoyed perusing them and I enjoyed the wide range of quality of some teams really put a bunch of effort into it and some of them are these post apocalyptic wiki wastelands like the document from twenty twenty well not even twenty. I don't know, two thousand f ive that no one's touched in a long time. I remember I'd come across teams where the someone had taken the time to take all the team's pictures and put them on the wiki, but they were actually like a visual graphic of the corporate badge of the person in like a grid for each team member, and I was like, oh wow, hats off to you. I am copying this. Yeah. I don't know why I like that so much. But I did it. And then you can tell when someone had a person on the team who cared a lot and they left like seven years ago and so everything is just Yeah, nothing is out of date. It looked really good, but all the information is seven years old. Like, what is this project? I've never even heard of it. It's because it died six years ago. Okay, last comment on the wikis at the big tech companies. But one of the things I really thought was interesting was there was a team, and I actually met the the engineering manager for this team at my big tech company that was in charge of the wiki system. Yeah. I can't remember what what this team called themselves, but they had a real challenge on their hands because one of the most important things when you're searching for content on the internal corporate wiki is up-to-dateness of the content And I just thought, man, what a challenging job to keep all that it's just a total Was that a custom thing at at your company? It was a fork of MediaWiki, I think. Oh okay. Like heavily customized. We just used Confluence. Oh that was probably very expensive. I'm sure it was. And there was also still a team that had to manage it. Yeah, yeah, yeah. You were you were probably like Atlassian's biggest customers, my guess. Yeah, I'm sure we paid him a ton of money. But the search was never good, but I I don't know how you would I don't know how you would make it good at that scale with someone else's software. So we actually had three wikis at my the at my company and it was like there was like a corporate like company wide wiki that was hit or miss and then there was like an organization sp there were two organization specific wikis. Totally separate infrastructure or or they were like sub pages in one global one? No, no, no, like totally separate. Like I remember now that two of them were confluence, but they were like different confluence instances, and then one of them was the media wiki PHP thing. Okay. Wow. Oh, and our team had two. Our team had pages on both because like the one of the wikis had better integration with the internal metric system. So you could like drop images for your dashboards in there, but the other one didn't and so it's like, but you still had to have one just because I don't know . It was like crazy. I know we've talked before about the feeling of running across someone that some some project or some person that that opens your eyes to what a whole giant chunk of many hundreds of people do at the company. I feel like that's even easier on a wiki where you're clicking around and then you hear about some oh this this looks very important and I've never even heard of it and it's got all these tracking things. Someone's stressed out about it. Yeah . I can see the current engineer that's on call. His face is right there on the homepage. I can see the live video feed of he types at his keyboard frantically. Oh man, I remember I I really wanted to know how a particular technology worked at like a famous AWS technology. And so I went looking for the wiki page and I just could not find it for the life of me. And I and I concluded from that that either A, this team is like super stealth mode and does not want anyone knowing how it works or B here I go A or B again or B they actually have another wiki that I just don't have access to Yeah There probably is some law about how no matter how many wiki instances there are , there's one more. There's one more than you know about. Yeah. It's uh that's called uh Jameson's Law of Wikis. Ah, thank you. You're finally gonna get it. Accept it. Yes. Yes. And I knew I couldn't call it Jameson's Law myself because that's one of the other laws. Someone else has to go Yeah, there's another there's a law called Dave's Law that says you can't name a law about yourself. No, there is. There is a law that says you can't name it yourself and it's also not named after the person who created it, I'm pretty sure. Wouldn't that have been the greatest act of irony in hypocrisy if it was named after them? Oh yeah. Yeah, totally. Yeah. Anyway, going back to the actual question. What about team priorities? Because we've talked about your customers and kind of who you're working with, but team priorities is a little bit that should be easier. Yeah. Like your own team priorities? Maybe it's hard because they change all the time. Yeah. I don't know what my own team's priorities are. This could be hard because your team actually does not have a clear priority or vision and is sort of just at the whim of the latest whipcrack by someone with the letters VP in their title or whatever. Sure. Or it could just be the you don't know more, which is I think way more common at a big tech company. Yeah. But you should be able to ask your team lead or manager what your priorities are. And and they should be you might not be paying attention. They should be talking about what this is a lot, and it should be written down somewhere and and sometimes you have to infer priorities based on what you see in sprint planning or stand-up but you know what this all of these questions this this is exactly the stuff you should be asking in your one-on-one with your manager. And a lot of times people ask us, what should I ask in my one-on-one with my manager? And I'm like, read this question because every question in here, like what are my team's priorities? What are the organization's priorities? What are our customers and what are their goals? What is how can I best contribute to the overall success of the company? If I had people asking me this in my one on ones, I would be thrilled to explain that to them. I would also ask, why haven't you been paying attention? 'Cause I've been talking about this. Maybe I'm maybe maybe I'm not that clear of a communicator. But but no, but seriously, like ask these questions in your one-on-one. This is what it's for, and you will get these answers. And a and a magical thing will start to happen. When you ask questions like what are our customer team's priorities, your manager will start to perceive you differently. Your manager will perceive you as someone who is not just turning the crank and doing the work they're assigned, punching in and punching out and just doing what they're told. They will perceive you as a contributor who can add value to your team and not just have to be told what to do all the time. And when you get that perception in your manager's mind, it will change everything about your job. When your manager sees an opportunity to do something bigger or cooler than what you've been doing, they'll think of you and not and not your cow orker. Because they only have one slot. You pushed pushed your coworker out of that slot. Right, good job. You crushed crushed the career aspirations of your coworker. But the point is you want to be in that prominent spot. And and I'm only saying this because you know this person says, I want to be promoted, I want to be more impactful, I don't want to get siloed. Great. Put yourself out there and tell your manager that you don't want the well, ask your manager these questions that demonstrate that you're inquisitive and willing to contribute in more ways than just cranking out the next ticket. It's also easier to influence the priorities of your team if you understand what they currently are. Yeah. It's I think every developer on a team has stuff they think they sh should be doing or the team should be doing. And there are varying levels of connection to existing business priorities and reality. Sometimes there's just a developer who has a pet project that they think is awesome and you think I'm glad you're excited about we're never gonna do that. It just does not matter or or will not have an impact on what we care about. It's it's easier to have an impact and suggest things that are helpful if you understand what you're trying to do. So it's not just sort of, oh great, now I can go do the priority more effectively, but you can say, ah, I understand the priority and I have this idea on what will help us achieve it, or I think we should s yeah change it slightly. Right. And if you don't understand what it is currently, you won't be able to argue coherently for why it should be different. That is so, so true. I can't tell you how often people come to me because right now I'm in charge of our our cr product roadmap for the company. And people often come to me and say, like, Dave, I think this should be a top priority. And I'm like, Oh, thank you. Can you please tell me how it ranks against these other thirty-five priorities? You know, and they're like, Yeah. Uh it's probably like number thirty-two. You know, I'm like, great. Now I now I actually understand. It's just so easy to be like to say this is important. But it's a lot harder to say, this is actually seventeen, it's in position seventeen on my important list. Yeah. So that's great. Just having more context is just so so useful. It is. And that's how you get it. You ask. Well have we answered this question? Well I think so. We certainly talked about big tech corporate wiki strategies enough. Yeah. Oh, I f I had forgotten about those. Me too. Nostalgic. Honestly, they were great. I thought I'd be nostalgic for confluence. Didn't it kind of feel like you your team just couldn't exist at one of these companies unless it had one of these pages? Yeah. Like it it made your team real. Yeah. It's like a charter. Yeah. It was almost like if you tried to schedule a meeting with someone else and they were like, who are you? And you didn't have a wiki link to point them to, they'd be like, you may as well not exist. Then you Thanos snap devolved into dust. Exactly. Honestly, it was great, man. I could l you could learn so much. And I just realized okay, last riff on corporate wikis. I realized that one way to scale an organization to a large number of headcount is to write these things down. Because after a certain size, if you have if you are a member of a team that interacts with other teams at the company, there will come a point in time where there are so many other teams that you will do nothing but explain what you who your team is and what you do for 40 hours a week because there's so many inbound inquiries about it. And so you just you have no choice but to write things down. And I just I really kind of loved that that forcing function that large organizational scale had on us to do efficient things. Because if you didn't, you got insta-crushed. Yeah. I didn't thought about it that way. Wik wikis.. Oh We're good . We are so cool, Dave. You and I are so cool. You should see me at parties when I bust out the wiki topic. It's like people just like circle around me. Say more about how you had three corporate wik is. Wow. Hanging off your every word. And one of the wikis used camel case for all of the keywords. Oh wow. Oh. Tell me more about your tagging instructions. If you want to be interesting at parties , what should you do? Well don't listen to this show . Start step one. Unsubscribe. Or if you want to get a question answered, go to soft skills. Ah, that's where I put the Patreon money. The cash to let me know. Directly my my quality of sleep trends up or down depending on how we're doing. Yeah, do you want Jameson's toes to stick out of his hundred dollar bill blanket at night? You need to join Patreon. So Jameson's toes don't get cold. It's like a quilted Benjamin's. I throw the blankets off at night because I get too toasty. Oh he's hotster. Yep. Bothers my wife to no end. Okay, well I need the blanket, so keep the keep the Patreon going . Oh we we appreciate you for listening and for asking questions. Anything you do to contribute, including just your your the bits going into your device makes us feel great. Thank you. Alright, we will catch you next week.