Soft Skills Engineering - Episode 9: Deadlines and Titles

Episode Date: May 2, 2016

In episode 9, Jamison, Dave, and special guest Layne Mosely answer these questions: As a software developer, is it better to put an aggressive deadline on myself? Or should I let it be open ended? What are the effects of these two approaches on me and my team? What do all these titles mean? Technical lead. Senior software engineer. Director of engineering. VP of engineering. CTO.

Greetings, everyone on the internet. This is episode nine of soft skills engineering. I am your host, Dave Smith. I'm your other host, Jameson Dance. And today we have a very special guest visiting us, whose name is Lane Mosley. Hello there. My name is Lane Mosley. I'm currently a software engineer at Bloombuilt. And we make the day one journaling app for iPhones. And I've been doing software for about seven years and I really like writing code and I'm super excited to be on this podcast. And we're super excited to have you. So welcome, Lane. Thanks. All right. Today we have two questions to answer and I'm just going to go ahead and pass it over to Jameson to ask the first one. Sure. As a software developer, is it better to put an

aggressive deadline on myself or should I let it be open-ended? What are the effects of these two approaches on me and my team i'm surprised there was no mention of whipping and flogging on this one i mean deadlines those are consequences which are different from deadlines that's what happens when you miss the deadline okay i thought you just whipped people until they met the deadline oh like or just assume they're not going to and just start early isn't that what they did to slaves in like egypt to build the pyramids yeah it clearly worked there so yeah those pyramids are they've lasted longer than than all software startups combined so that's probably true um case in point all right so deadlines what uh should i let it okay

an aggressive deadline like i've heard people say like without a deadline i'll just keep going or actually another phrase i've heard is that software is a gas and it will expand to fill the calendar space that you put it in have you guys ever heard that yeah i think that's a variation on a quote about how work will expand to fill the time allotted for it yep and i've seen that happen like i that's a real thing with software but there's also this sense that um we don't like deadlines because we are we are like pure craftsmen building these works of arts that can't be rushed and yeah there's kind of this balance between pragmatism and and art and craft that is inherent in this issue of deadlines i think yeah yeah definitely have you well have

any of you had really bad experiences with deadlines oh i think everyone has had at least one of those um the worst kind of deadline is the one that's really it's it's arbitrary and it's totally too soon you know and it's like why why am i working toward this it's just really demotivating and that can happen on one hand you mean a deadline that uh is maybe made to try and make you go faster but it's that there's like no way you can get it done in that time well like that would be like one specific example of an arbitrary deadline but just a deadline that whose whose rationale i cannot understand and no one will tell me you know it's like i put this deadline out there and maybe the ceo chose it because he or she just wanted it to be that way you know and

it's like that to me is the most demotivating kind of deadline and i think that would actually make me go slower you know to know out of spite no no well well maybe okay i think jameson just taught me something about myself okay the toughest deadlines that i've come across i think or is when you know a ceo or somebody shows some partners a slide deck and then says hey this is done check out how cool this is and then they come back to the engineers and they're like oh hey by the way they're expecting this in two weeks and you're like what you haven't even started on that thing oh man that is the worst it's so bad and meanwhile you're trying to finish the last uh arbitrary deadline yep to be fair i have not faced this too much in my career which

thank goodness yeah you're lucky it's it's brutal so what do you think should you put like let's say you don't necessarily have one of these deadlines should you put one on yourself to make yourself go faster or should you just say my beautiful art will be done when the art is done no one put a deadline on michelangelo they probably actually did i'm gonna google the sistine chapel right now and and i'm sure he had a deadline yeah i mean there was money involved so there had to be some kind of deadline yeah i mean money isn't gonna last forever unless you happen to be funding the painting of the sistine chapel in which case i guess it pretty much would

uh well maybe maybe a better question so we've talked about clearly there are bad deadlines right like ceo rolls out of bed reads the clouds is like it will make me feel good if i tell them it's gonna be done in two weeks um are there ever good deadlines definitely there's gotta there's always good deadlines i think so too yeah what what makes a good deadline lane you sounded pretty pretty adamant about other good ones. Yeah. I think there are some that, um, when all of the engineers, uh, have weighed in, not maybe not all of them, but at least a good portion of them, or if you have a really good, you know, engineering manager that can, you know, accurately assess the amount of work that's required and they work, you know, with the

business portion. Um, those are usually pretty good, you know, as long as everyone's weighed into it and and everyone's bite bite off on it then i feel like it's great and and that also gives some accountability to the engineering team you know they don't feel like it was just like some date picked in the future because that's when we wanted it it's like oh wait this is when we think we can finish this work so i actually work for a company that has um i'd say some pretty important external deadlines i think there are deadlines about here is when we want to get stuff done because it'll be better to get it done faster you know but i work in education and they're very built-in deadlines the the semester starts at this date and if you want your software

to be used it has to be done this amount of months before the semester starts so they can get it ready um so in my experience the way deadlines interact in that case is like there's actually a deadline at this date there's no more you can do so it's it's more about cutting the scope of the work yeah to meet that deadline where like dead is the emphasis on deadline right like you can't you can't just be late like then it's over you missed it so so it's more about managing what gets done in time for that deadline and that's pretty different for when you're kind of controlling your own product and you're using deadlines to schedule and to motivate and and stuff but it's not uh one one month later just means your product is out one month later it doesn't mean you've

missed some some arbitrary period of time or you've missed like a one year opportunity because you're one month late yeah in your case yep have you guys ever seen the phenomenon where a deadline gets put in place the team starts working for it and as the deadline approaches the team starts working more and more and like more hours in a day or working more feverishly to meet that deadline and there's this phenomenon where you just rush and rush and rush and you get it done and it just barely sneaks out and do you think that's positive or negative that just seems to me like what human beings do you know like yeah yeah i don't know you just you you wait until the last minute to do things i mean i know a few people that don't do that that are you know they do things up front

and that's awesome but i think generally you don't do that yeah that's how i do my taxes and mow my lawn and clean my room and also how i build software for better for worse it's the mow my lawn do my taxes uh agile yeah that's what i'll tell the irs i'm being agile i'm just waiting till you audit me to do my taxes haskell calls that lazy evaluation and it's a huge language feature it's great yeah um oh go ahead i was so the question then is without such a deadline maybe you would not ever push yourself you know is that possible is that a thing i think it's a thing um i know a certain type of engineer that they can spin on the same amount of work for a long time in fact i know a guy that worked at intel i worked for this guy and he worked at intel back in the 90s

and back in the 90s intel was investigating you know some mobile stuff i think super new back then anyway they hired a whole bunch of these phds and they designed some software for two years and never wrote any code because they have no they have no date in the future they were just like go investigate this stuff right and the engineers were like that was the best two years of my life no bugs yeah if you don't write code you don't write bugs right um but yeah i think that happens you know and was that was that project basically a failure uh yeah that's what he told me he said they they never did anything they spent millions and millions of dollars and nothing came from it they just had to write it off the end so oh man so bad so so i

think you're saying there's value there can be value in a forcing function uh depending on your team but uh like in this case obviously a forcing function would have been really nice yeah you know to force them to get something into production or something um but at the same time does it do you think uh having an aggressive deadline can also have other effects on your team like um maybe harmful effects like you rush something out and you accrue a lot of technical debt and then now you have crappy bugs you have to deal with for the next year yes yes I think you're resounding yes yeah I think there's there's like this bell curve of deadline aggressiveness and pressure where if there's none at all you're way at the left end of productivity where you just

have nothing except your own inherent motivation and it's really easy to be distracted at that point by some cool new technology or architecture or just iterate on a product forever and ever without without releasing it without releasing it yeah and then at the other end you have crazy unrealistic deadlines that to me are incredibly unmotivating and there's a sweet spot in the middle where i feel like the work is challenging but i i can see a future in which i can accomplish all the work whereas if the deadline is too aggressive i just i'm like there's no way i can do this and and and i check out a lot so they're both equally demotivating on both ends of that curve is what you're saying yeah it's probably a lot more fun to be on the left end

where there's no deadline but but it might be yeah it's way more relaxing um maybe long term it's demotivating it's way more stressful to be at the other end of high intense pressure but i think you you miss out on a productivity window in the middle i agree and this is actually why despite the bad press that Agile sometimes gets, I really like Agile, or at least the one principle of Agile that says we focus on a continuous delivery of software to users. The idea is you force yourself to put code in the hands of your users frequently, whether it's on a weekly schedule or maybe you just do it every couple hours or whatever. You're forcing yourself to be production ready all the time, which then automatically puts in place this feedback loop

where you can iterate um whereas if you only do that once a year or with no deadline at all um i think that unfortunately human nature will just tend to sit on it go to our intel 90s mobile playground ah yes that playground uh i once worked on a product for two years and we we thought we're gonna ship this when we've got it right and we we we literally came full circle on that thing like four times it just you mean like changed some feature sets and then ended up with those similar feature sets added back in yeah i don't know if jameson man i don't know if jameson knows what i'm talking about but lane and i work together he probably doesn't know what you're talking about yeah yeah anyway um and

so so two years i never saw the light of day is that what you're saying it did it eventually did see the light of day and but only at the end of this four iterations is that what you're saying yeah and and unfortunately you know we we never figured it out because we never gave it to real people that wanted to use it it's bad and um i can contrast that to what i do here at day one we we ship to our beta users um at least once a week and it's like fantastic because we get immediate feedback on what we're doing it's so good so so so it sounds like you're saying um the value of having a deadline is it doesn't matter uh it's more the the inherent value in having to in being forced to hand it over to people is that kind of your point where um it

doesn't matter how long you plan for it uh if as long as you have a date where you say we're going to be done and give it to real people maybe i'm misinterpreting what you're saying i think i think that's right because and i just speak from experience you know contrasting you know different experiences that i've had engineering is i've had the experience i mentioned two years and it didn't work out whereas here our deadlines literally are when our beta test group which is pretty big when they're pretty happy with it then we know that it's ready and so you know we have you know weekly goals to you know ship it to them and when they're generally happy then almost all of our users are happy we haven't had any time you know when that hasn't happened so yeah so i

think there are kind of two contrasting worlds here um one is where the deadlines all come from within and their their kind of motivation and goals and that seems like it happens a lot more in the consumer software space where you own the product you drive the product you you're picking like here's what we want to work on and no one's no one's like clamoring for when it's going to be done and then there's the other world which is the enterprise software or to some extent giant consumer companies that are beholden to maybe like shareholders or things like that where people are like when is this going to be done i need to know so i can plan to train my users or plan like how the market's going to react or whatever um so dave you mentioned agile as like

you just focus on getting code out and delivering value incrementally and to me those two things seem kind of in conflict like yeah if you if you focus on iteration and delivering value incrementally you put less emphasis on big planning and estimating when things are going to be done by because that's not your focus but like true and you struggle to communicate that like long-term schedule to the rest of the yeah but but some people some customers will be like i'm not gonna buy your thing if i don't know when stuff is gonna happen like i i can't use it then like how do you how do you balance those two things that that conflicts between uh deadlines and schedules and short iteration that focuses less on when stuff is going to be done and focuses

more on getting stuff done so i mean the way that we do it at my current employment is we uh even though we ship frequently to production we actually only commit to customers and the rest of the business on a two-month release cycle so we put new code out but we only advertise new features and make them available like in the ui for example uh every two months and so we actually sign up at the beginning of the two-month period for the stuff that we will be putting out and we try never to go beyond two months because that just becomes uh the lying land where you just are lying about what you think you can actually deliver because it's just too far out sure but up to two months we do that and we actually do commit and we sign up and we say we will deliver this in

the next two months and that tends to give people enough time to do the things you just talked about and uh the other thing about people not willing being willing to buy your stuff if you don't tell them when it's coming i have a hard line we do not sell stuff that isn't built yet and so um because as soon as you do that then you get all kinds of bad incentives going on those are words to live by i'm not talking about selling stuff that isn't built yet like be our customer and in x months we'll have this thing it's more like uh you have an existing customer that really wants a feature they're already they're already your customer you're not selling them based on this feature but they need it for some upgrade or to to roll it out to a larger group and they really

want to know when right yeah like they they it's like a giant company and they need to plan around it and you can't just be like well in the next week we're gonna get this little bug fix done as part of our agile sprint like i don't know that doesn't work for them stupid bug fix when is this giant thing i need gonna be done um yeah and for us we just say it's either gonna be done in the next 60 days or sometime thereafter and okay sometimes they'll pin us down we'll be like okay it'll be this year you know yeah um but those almost always come back to bite us because the business needs change you know in like six months where it's like well we wanted to focus on this but we're beholden to all this stuff we signed up for so that's a case where long-term deadlines

can just really hurt so can i sum up what we talked about with deadlines what i think we talked about yeah please it feels like uh both really aggressive deadlines and no deadlines at all can be bad for very different reasons really aggressive deadlines means really high pressure if it's unrealistic then you just lose all motivation to work on it i don't think people perform super well under pressure often and then no deadlines means uh you can be scared to release stuff and you can also be tempted to just play with cool tech and solve things that are fun for you to solve instead of actual customer problems so there's a sweet spot in the middle where you're both motivated to deliver things uh quickly and focus on what's important to your customers but

you're not demotivated by there being an overwhelming amount of work or something is that kind of a summary of what we talked about yeah i think that sounds really good cool should we move on to the next question question answered ring the little gavel thing dun dun do you need a stamp answered yeah answered i can take a bite of my sandwich and that can be our question answered noise take a video of that jump jump put it in the release notes yep all right question two today i think it's my turn to read what do all these titles mean technical lead junior software engineer senior software engineer engineering director vice president of engineering cto what is with all the titles

uh i want to throw one other title in there which is his serene majesty archduke of computering which is my title i don't know what it means you're the only one that will ever have that title i think well that means your title just means jameson dance which is great it's very very clear yeah it doesn't fit well in the org chart though yeah it overflows all the boxes there's just a dotted line that is like way out on the left and then it points into the company um what do all these titles mean i think they can mean different things at different companies actually facebook is famous for uh oh yes having a different level of titles like they'll they'll generally hire people into lower titles than they were at other companies uh what do you mean hire

people oh they will like if you are a director of engineering you might come in and be an engineer a junior software engineer you might come and be the coffee gopher or whatever no but uh it's like they just mean it means more in context i think than absolutely and there is some absolute meaning but it depends a lot on the company yeah typically uh at the very tippy top of the proverbial pyramid it at least can identify that like a lot of time well actually that's not even true i was going to say like there could be a cto at the top of your engineering organization and that's usually the top but it's not like there could be a vp of engineering at the top there and there could be someone else there could just be like a quote head of engineering or

a director of engineering like that could all i don't even know so yeah i think from one company to the next there's just like no standard question answered there's nothing yeah not all knowledge is relative anyways so you can't know the truth of anything so so there is there is no reality i'm sorry why are you listening to this what you perceive is the subjective reality Speaking of perception, I believe that there is a generally accepted perceived, let's say, pecking order to the order of, say, leadership titles. Now, I'm not going to talk about like individual contributor titles, but in the leadership management track, there tends to be things in this order. And I'll just throw them out there and see what you guys think. But it typically starts with like a manager and then like a department manager, if your company is big enough, and then director and then VP and then CTO.

like that's typically the title chain on the management track is that similar to what you guys have experienced yeah i don't think i've ever worked at a company big enough to have that many levels yeah so it seems like you kind of you like subtract levels in the middle as your company gets smaller yeah i agree um you didn't talk oh go ahead no you go ahead i was just gonna say you didn't talk about um technical lead and senior senior versus normal versus junior yes let's talk about that next i i usually see that as a parallel track um of all like in the individual contributor title like to me technical lead is not a stepping stone into management where you're doing salaries and hiring and firing and things like that so i like to think of those as a

completely separate world but i've also heard the generic team lead or developer lead i guess developer lead is kind of the same as technical lead and i heard a recent uh recently a few months ago i heard a new title called icl which stands for individual contributor lead wait a minute it sounds yeah i know like my head just cracked open so the idea is that you can assign people to have influence in your organization but not give them management responsibilities and that would be an individual contributor lead in other words they aren't people don't report to them but they're responsible for influencing the direction of projects they make decisions they have influence but they aren't managers and i kind of like that idea the title the title is kind of weird but i

like the idea that is interesting i feel like at the places i've worked the technical lead role has has been a pretty even blend between uh tech actually tech leading like making technical decisions and or not even making them but helping guide and and uh i guess this is getting some of personal philosophy i don't think the tech lead should make all the decisions but they should help make sure the team is making decisions um but it also blends some management stuff like it seems like um the the lower down the pyramid you go the more okay it is to blend those things but you probably don't want your cto every day in the code base just like cranking out commits unless your cto is the only engineer yeah that's true which i guess happens actually i'm the cto

of my company lane lane was the cto of the company we worked at and it was a fairly small company and he was like coding the whole time so it doesn't depend a lot on what you do yeah so the size of your company at that size of company like really the cto like my role was just to do a little bit of meetings and write code you know and it worked out really good for us i think i mean i'm sure jameson has plenty to say well now i have to now i have to say it worked out no it was good it was uh and how many engineers were on your team at the time uh we had the company about i don't know was it 10 to 15 i think 15 was about as big as we got as many as we had you know and and i'll be honest you know when i i was a i was pretty young um engineer when i was given that responsibility

and you know i was i was excited about it because back then you know i thought you know titles meant career progression and i've since learned you know personally i don't find that to mean career progression anymore i find you know shipping great products to be more of progressing myself as a as an engineer um but tell us about that mindset like what was that like was it like leveling up a video game character or something like uh yes it was just like that um no i think you're joking but i think you're only partly joking yes you're right only partly no um i think when anyone starts in a career uh you know what a career means is probably a little bit different to some people uh when when i started my career as a software engineer uh i had a goal

and that was to become a CTO. I thought that was a cool thing to do and I accomplished that. And I soon realized after that that there was so much else to do. I hadn't shipped a lot of great products at that time and I feel more accomplished now shipping some great stuff than I did back then.

So I don't know. Does that make sense? As a CTO. say again yeah totally yeah i said so you feel more accomplished now not as a cto yes than you did as a cto yep yep exactly so at some companies i found that oh actually you know what let's go into the uh non-management titles now shall we yeah so like junior software engineer senior software engineer principal engineer staff engineer technical fellow what does all that stuff mean i was recently go ahead you can go ahead jameson i was going to say some of it is an

attempt at some companies to make a path for advancement through purely technical means if you are just a great engineer but you don't um enjoy the the just massive amounts of of people stuff you deal with in management the idea is they still want to keep and reward and expand the influence of those people so um some of it is like some of them will even be parallel pay tracks like there's a there's a one-to-one match between these technical roles and these management roles and they advance and pay similarly and i don't know you're just responsible for maybe larger uh technical decisions larger in scope technical decisions as you advance what were you gonna say lane uh i was recently part of this conversation um on the slack channel

and it was a it was a big argument about what qualifies a senior engineer and it all started from a from a a recruiter email that said um let's see what were the words oh it was seeking swift senior swift developer you know with five years experience oh that's the best Okay, so there's a couple problems with this, right? So Swift has been around for just under two years, right? And so the big discussion was, well, you can't be a senior engineer in two years, right? And I thought, well, I don't know if that's true. You know, it really depends on what senior engineer means. and in my mind you know a senior engineer is somebody that you just you don't have to hold their hand they can make decisions and they can ship stuff to production right um i don't know what do you guys think about that it was it was a funny it was a funny discussion i think senior is separate from swift you could be a senior engineer

and have two years of swift experience but maybe they weren't asking for five years of swift experience just five years of experience james and don't give the recruiter the benefit of the that's true that's not trendy yeah it's i'm supposed to just rant about how horrible recruiters are while simultaneously dropping these like humblebrag hints about how hot how hard it is to just be bombarded by recruiter emails oh my life is just horrible because i have to say no all these people that want to hire me i hate that if you can't tell um agreed i think senior is very vague absolutely and it to me it implies um maturity more than years of experience uh and i think i still do a lot of dumb things that maybe would not qualify as as senior engineer type

things i think it has to do a lot with your focus on delivering value maybe versus technical stuff like if you get bogged down into arguments over syntax or architecture at the expense of the product that seems like a thing a senior engineer wouldn't do whereas a senior engineer would would be able to integrate like yeah there actually are technical differences and some architectures are better for some problems than others and here's how we will use those things to ship products instead of just like draw a line in the sand and refuse or not know about them either. Yeah, that one is really vague.

And it only gets more vague as you move up the chain of these other ones I listed like principal engineer. What's the difference between a senior software engineer and a principal engineer? I don't know. And some companies will write these up. But what I have found is that most companies

that have this big scale, typically those labels are just there so that you can have a salary band. where you fit in there and and and you get you tend to get promoted from one level to the next simply because you topped out on the salary band of the level you're in um and that was my experience at my last company and it was weird it's like well you're now a principal engineer i'm like oh great i'm gonna go back to my desk now and do the exact same thing i did yesterday before i was a principal engineer now i have a slightly bigger paycheck yeah i've had the same

experience in a company like we were talking about what my you know just negotiating salary and then they gave me my title after that after they figured out where your salary was because that's all that matters that's just that's case in point i mean that's so i think if people are striving for that next big title um you might be disappointed you know i mean it's just you know sometimes the title can mean something uh like a job change But usually that only happens when you go from the sphere we just were talking about, like engineer, principal engineer, staff engineer. You leave that sphere and go to the other sphere of manager, director, VP, CTO. Then, except in the case of Lane at that last company, then your job will materially change and the things you do day to day will generally be different in my experience.

Yeah, at a certain scale of company. Right. um i do want to talk more about team lead because to me that seems like the most interesting one because because of the mix i feel like on most of the teams i worked on the team lead has been technical um but you're still responsible for the output of the team as a whole yeah where as a senior engineer you're you're responsible to help your team and and i think you should be like mentoring more junior people and contributing to architecture discussions and improving the product and the code and stuff but as the team lead like you i think you are measured by the

team instead of just by what you shipped or something yeah that you're absolutely right and so you in other words you have more responsibility put on your shoulders yeah even if you're still coding most of the day probably the things that you are coding are determined more by what the team overall needs than what what is interesting to you or however you assign tasks normally within a team to individuals and even though we've been making fun of the fact that your title doesn't often change the way that you do your job. It does impact the way that your peers see you. And once you've been dubbed the team lead, suddenly you have a lot more influence over the team that you didn't have before. And your attitude can be pervasive in the team. It

can spread either positively or negatively. And, you know, the way that you respond to management decisions in front of your team, it carries more weight and it tends to propagate away from you a little farther than if it was just you know dave sitting in the corner being mr individual contributor now it's dave the lead suddenly everyone starts listening yeah has that psychological effect your team carries more weight too because now they have to carry you around on those pallets where they have the poles in the chair and then they put them on their shoulder jameson's describing our daily ritual when i was his cto just to make that clear so your job materially changes because you're literally elevated yeah i i love what you said about oh go ahead oh i was gonna say i i what

you said dave is totally true i i felt that when i became you know assumed the cto role and personally like i didn't like it very much because yeah i had no desire to like be higher than anyone else i just wanted to be on the same level and i tried really hard to do that but i still was treated slightly different by some people. And I did not like that. Me neither. That is the hardest part of leadership, I think. Yep. It really is. And there's a really, a lot of people really enjoy the individual contributor lead style role for that reason. Like I want to have influence, but I don't want to have the title and I don't want to have all the extra responsibility because I don't want to sacrifice my relationship with the team in this way. You know, I don't want

them to see me differently. I don't want them to, to value my opinions more just because of my title. i want to just be part of the team yep i i think you said something really interesting earlier dave about how your title can affect the distance to which your opinions propagate um in some ways it sounds like that's i think a lot of that is implicit just in in the culture um some people are respected not that others aren't i guess but but some people just kind of become identified as they're really good at this thing or they're really dependable in this way or something and sometimes titles are a way to reflect that implicit uh structure that arises but sometimes they're an attempt to influence that structure as well like maybe there's someone who

you want to elevate their opinion because you think that they're talented but maybe they don't speak up as much as they should or they're less inclined to like push their way into conversations yes what do you think about that as using titles as a tool to explicitly shape the culture or the team instead of just like oh this person talks a lot and they're smart so they're the team lead oh no yeah so that is that is absolutely a tool that i want to employ in my current role where i say so and so on my team is excellent i want more people to be like them well what's one way that we can do that is we can assign them to be the lead of the team and maybe it's not permanent and only if they want to do it but that will have the effect of like um causing people to uh like

let's say pattern match from them a little more than if they were just a you know a team member without that title yeah and that actually that can get into some of the unintended consequences of this too because even if you don't decide i'm trying to make people be like this person that that might happen too so if you choose someone who uh has values or or habits or attitudes you don't want then then those are going to influence your company maybe for the worse yep you pick up the stick you get both sides and then the other side of this coin is that if someone is in a leadership position and they are being toxic or negative or harmful in some way, their toxicity has more amplitude than if they were just without that title. And so you can make changes that way

as well. So works both ways. Yep. All right. I have one more thing to say about this. Hit me. So on the subject of titles, I can't help but think about The Office, the TV show where dwight has the title assistant well dwight thinks he has the title assistant regional manager but but the actual regional manager calls him the assistant to the regional manager and i just think that's so funny well it's so funny because to dwight like it literally means everything you know and it's just like demeaning to him to not be called the right thing yeah like two little words he thinks it reflects who he is as a person and i think a lot of people lane you it sounds like you thought that too earlier and and it's some people feel that way about salary too like

these are things that reflect how valuable i am as a person so they want to be more valuable and they want more titles and stuff yeah yeah absolutely and you know i i'm okay to admit that you know titles at one time were important to me but you know as i matured as an engineer They just became less and less important because I was finding fulfillment in other areas, such as seeing happy users, writing really good code. Those are the things that became more and more important. And that's not to say that if you do currently value the title and that's what you strive for, that that's necessarily bad. Because I think that can be a really important career management technique for a lot of people. and it really can help lend legitimacy to people who otherwise maybe are biased or have people

biased against them for other reasons sure maybe maybe because of a lack of privilege or something the title can help to offset that bias and i think that's perfectly great yeah yeah that's true i i was gonna say the the same thing and um i have other one other thing that's pretty interesting um as far as using titles as career progression when um you know i left i.tv and i started looking for another opportunity as a prior CTO, it was, it was extremely complicated. Oh yeah. Like I, I was not prepared for that. And, um, it, it was very hard for me to get my shoe in as, as just a normal developer again. Uh, and so, yeah, I don't know, not much else to say about that, but it is a thing that happened to me. And so I thought it would

be interesting to say so. Awesome. That was really good to say. Anyway, I'm done. That's it. question answered done done damp awesome uh lane it's been so great having you on the show today yeah if someone wants to get in touch with you or meet you what's the best way for them to do that show up at his house at this address yes no uh actually my preferred communication is linkedin if you no i'm just kidding it's not that um you can find me on twitter uh it's at lane mosley uh but i'm kind of a hermit so you don't see me on there too often but sometimes you do um okay you can find me there or my phone number no i'm just kidding no not so tweet tweet at me and then i will talk to lane on the phone if you uh if you tweet at me

if you tweet at me though i will respond and you will be happy so awesome uh jameson where can people find more about soft skills engineering the podcast the best podcast in the internet the best podcast inside of the internet outside there's no guarantee uh they it's probably the twitter account yeah just at soft skills eng is where you can uh follow us for updates about stuff about the show you can tweet us questions that we will answer and if you want to you can also follow dave and i i'm jurgison at twitter i'm dj smith 42 yep thanks for joining us. We'll catch you next week. See ya. Farewell friends. Goodbye.