Soft Skills Engineering - Episode 294: Unqualified internal applicant and speculative specs

Episode Date: March 7, 2022

In this episode, Dave and Jamison answer these questions: I work in a squad that has been slow in delivering. Squad leadership (including myself) concluded we need a staff engineer (one level above senior engineer) to help guide tech directions and to support other engineers. Unfortunately we have received only a single applicant- senior engineer “Brett” who’s already on the team. Brett is a good engineer and has a lot of great qualities - but falls short of the “staff” level. Our tech lead “Chris” doesn’t think Brett is suitable due to bad technical decisions Brett has made in the past. Chris also thinks Brett should have been discouraged from applying in the first place. (Brett’s manager is outside the team so has less visibility on what’s happening inside the squad) We’re suddenly in a bind. If we give Brett the role we are in the same situation as before but having to pay him more. If we don’t give him the role we run the risk of losing him in this environment - which would be very bad as he is a good engineer! Should our decision be down to how Brett interviews? What could have been done differently? I recently did some extensive planning for a feature with a back-end engineer where we negotiated what the GraphQL api would look like. As I was finishing up my feature work, I realized that they departed from that plan and didn’t tell me. Now the feature is late. They’re having to make adjustments because the departure from the spec made it impossible for the front-end to handle the data. I’m having to do more work because they used a completely different architecture than what we discussed. What’s even more frustrating is that the end result on the backend is going to be exactly the design that I initially proposed (this is documented), which the backend engineer shot down when I proposed it. I feel angry that they dismissed my technical expertise. This has also eroded my faith in collaborating with this person. Retro’s coming up. How would you approach retro? What outcome do I even want here? I don’t think more process is going to be helpful (I spent 6-8 hours on the planning portion of this feature). I am starting to wonder if my perception as a primarily front-end engineer prevents the back-end engineers from lending me credibility.

it takes more than mumbling scope change every time your work takes longer than you expect it to to be a great software engineer this is episode 294 of the soft skills engineering podcast and i am your host jameson dance i'm your host dave smith soft skills engineering is a weekly advice show where we answer your non-technical questions about the technical field of software development and if we ever go over our allotted recording time then right as soon as we hang up i just complained to dave about scope change man the scope of that episode just really changed i was trying to wrap it up and all of a sudden you added another facet to the question which threw off all of my estimates scope never changes to get smaller do you ever notice

that i mean it does i guess but right only only when things are late yeah oh now now we can shrink the scope oh oh those essential features hmm turns out they're not so essential there is probably some kind of universal law about the amount of effort per unit of scope reduction required as as compared to the amount of effort for unit of scope increase required it's like effortless to add more scope but takes real thought and discipline and effort to remove scope you could also probably plot a curve as as the deadline approaches for how much effort it takes and mysteriously the effort to remove scope changes a lot as the deadline gets closer uh that's not what this well i mean it's kind of what this show's about anyways let's talk about other stuff

all right i agree let's see this episode is sponsored by ops level ops level makes shipping great software easier you'll hear more about ops level later in the show i also want to thank our tremendous patreons patrons i can't let patreon steal that word weekly shout outs to the stochastic parrot alice jost andrew pollock the yeet your job podcast avery sturtzel ian walter arunduna kashokson ohio cameron hall patreon.com.au we're hiring ira chan monkey face emoji jonathan king testing is documenting.org eladapo fadye i escaped from tarkov but can't escape javascript ragnar harrison timmy gara brandt nick hathaway travis sanders dennis bogan of raiden canes john grant i bought winner on nick cantar and philip john basile thank you to y'all you grow wiser

by the minute i can just tell if you want to join this crew or if you want an invite to our slack community then you can go to soft skills to audio and click support us on patreon any dollar amount will get you an invite to the slack community and then whatever dollar amount it says on there gets you a shout out i can't remember right now but whatever it is it's a great deal yeah it's like it's only a few million dollars yeah it's not bad you want to read our first questions i do this comes question yes i'll just read the first one okay thanks one of one of two okay this comes from an anonymous listener who says i work in a squad that has been slow in delivering squad leadership including myself concluded we need a staff engineer which is one

level above senior engineer to help guide tech direction and to support other engineers Unfortunately, we have received only a single applicant, senior engineer Brett. That's Brett in air quotes, so I think this is not really Brett's real name. Brett is already on the team. Brett is a good engineer and has a lot of great qualities, but falls short of the staff level. Our tech lead, Chris, again, Chris in air quotes here. Our tech lead, Chris, doesn't think Brett is suitable due to bad technical decisions Brett has made in the past. Chris also thinks Brett should have been discouraged from applying in the first place.

Brett's manager is outside the team, so has less visibility on what's happening inside the squad. We're suddenly in a bind. If we give Brett the role, we are in the same situation as before, but having to pay him more. If we don't give him the role, we run the risk of losing him in this environment,

which would be very bad as he is a good engineer. Should our decision be down to how Brett interviews? What could we have done differently? Interesting. so this is someone applying for an internal an internal promotion basically yeah i mean one thing you could have done differently is explicitly put in the job description this position is open to everyone whose name is not brett it's a hard requirement our systems couldn't handle a brett legacy code that's all you have to say there's some legacy code here yeah it's just like how

you mumble scope change every time you're late, every time you want to make an excuse for why you can't do something, just legacy code. So our tech lead, Chris, doesn't think Brett is suitable. I mean, you should not give this person the role. Well, what if, what if you do give them the role, but then you offset the issue by applying a broad sweep of title inflation to everyone? So you say, yes, we're now calling you staff engineer. And if you look at this table, all the duties of staff engineer are actually what the old senior engineer duties used to be. And we're now calling new college grads senior engineers. How do you explain the lack of a pay raise, though?

We've done some budget refactoring. Well, for that, you have to do monetary inflation, where you actually change the currency to use some other currency that can be arbitrarily pinned to the U.S. dollar. this is you're gonna get paid 10 more company coins yes than you made in dollars and good news you get to do an ico for your company as well which will be kind of fun yeah don't give you should not be threatened into so this is interesting it it kind of overlaps with um folks asking for raises in order to stay and and maybe there's a number at which you feel like oh i don't know if they're worth that much money but we want them to stay the fact that it's a promotion though makes it more clear cut in my mind that if they're really not ready for it you

are not setting them up for success and and you're going to create more problems by promoting them than uh if if you were to not promote them and they were to leave so you you would trade losing one person from the team versus the problems created by promoting someone prematurely in the team yeah i would tell brett we don't negotiate with terrorists and then just let him interpret how he will how he wants to yeah i think i would that's a really bad precedent to set that if someone wants it and they're not qualified you give it to them anyways because otherwise they might quit it kind of dilutes the well separate from the fact that it doesn't solve your problem at all it also creates an expectation that that's kind of how it works with other developers

even if you don't change what you say the qualifications are for a staff there's what people say they are and then there's the qualifications you can infer by looking at everyone who has that title yeah and and this will change the inferred qualifications which will dilute the staff level which will cause title inflation it's perfect it's exactly what i said oh true i just don't see how this helps you i mean it's not my team so it's a lot easier for me to say, just risk losing Brett. Yeah. Like I don't even know Brett. Yeah. I don't think he's great. I don't think he's, I don't think he's all that. I mean, what, what broke down do you think to lead to this situation? It sounds like there's a split between kind of the work that

engineers do and who their engineering manager is, which is not a negative, but it is certainly a trade-off. So maybe Brett has been having conversations with their manager about how to get promoted and boy this looks like an easy solution for that oh there's a vacuum over there i'll jump into it yeah and and i'm not responsive like the manager might not be responsible for the output of this squad so maybe maybe it just is a pure win for them if brett gets this promotion yeah maybe the manager is like man think of all the paperwork i don't have to write if if they'll just give brett this job yeah brett is happy my life is great problem solved oh man but here's what's going to happen though is look if you're not going to give this job to

brett which i think you probably should not i agree with james you got kind of two ways to make this to diffuse this situation number one well maybe three ways number one you could talk to brett directly as the team lead on the team that brett's applying to and say hey brett thanks for your application we don't think you have the qualification that we're looking for for this position right now you know maybe maybe in the future we're gonna keep looking like that's one way or you could go to brett's manager and say hey brett's manager listen brett's really not qualified for this job you need to talk him off out of this one you know and then brett can talk to his manager and then get and then rescind his application both of those are probably reasonable

outcomes or the third one is you could get out there and hire someone like you really could still like it's not off the table and you could say look we're going to take another month to see if we can get a better candidate pool because we didn't get enough applicants to make a decision you just kick this can down the road 30 days future you will be smarter and wiser yeah you more capable of solving this problem 30 days of growth current me is cursing past jameson for unwise time allocation but future jameson will have solved that problem yes when the future arrives this i feel like there must be a tie-in to the scope creep comment from earlier on that yeah this is interesting because giving feedback about why someone did not get the job is fraught

even if you're never gonna see that person again it's like how do you tell them you weren't good enough without offending them or causing hurt feelings and the answer is most of the time you don't you just keep it very vague and so there's no closure but it's okay because you don't have to see that person again but i feel like you have to tell brett something more specific besides it wasn't a good fit and and good luck with all your future endeavors i.e like go away because you need to keep working with them and and you can't just kind of shoo them away with a vague dismissal does that seem right to you do you feel like you owe brett more clear feedback than you would for just any arbitrary candidate who applied who wasn't qualified i mean given that you work with

brett and they're a team member yes i think you owe a little bit more but i think it's brett's manager that really needs to pick up the ball here and deliver that so what you're saying is that the the team could reject brett's application give the feedback back to the manager have the manager deliver the feedback is that right i suppose yes and it doesn't have to be like here's 17 paragraphs on why you know the growth areas for brett that he needs to do you know it can just say like look we're looking for the following three things and we haven't seen Brett demonstrate those yet. Yeah. I mean, I have a hard time understanding how Brett would understand the information as the question asker has presented it, where there's a problem with the squad and the solution to the

squad is bring in someone with even more experience and think, I know I will be that person. Like I'm already on the squad. The problem's already there. I just am not paid enough money to solve this problem. If you would just add more money to my bank account, I can solve all these problems. i've been holding back yeah i've been sandbagging this whole time so that feels weird to me that maybe maybe that wasn't communicated to brett they just saw like a flyer posted on the in the cafeteria something and grabbed a little tear off thingy and sent the resume in yeah and that's that's really a a strong possibility that brett actually doesn't have his heart super set on this you know and you might want to feel that out with brett's manager go talk to them and say hey

what's brett really you know is brett gonna leave if we don't give him this job let's talk about it and then get the manager on your team so you can make a strategy that gets everyone's needs met yeah i mean if there are specific concerns about why brett isn't a good fit that's kind of not kind of that is the manager's job is to help brett develop and improve yeah so you could deliver the no with the manager having some kind of plan to work on those things. And maybe if there's another opportunity in the future, then it'll be a better fit. Yeah. See, that's a way better message for Brett's manager to deliver is to say, the answer is no, not at this time, but here's an individual development plan for you that I think will get you there within six to 12 months so that

you can be ready for the next one. That's awesome. Yeah. Instead of making bad decisions, make good decisions? Step one. That's actually a question is, should anyone tell Brett, hey, the main reason we're doing this is because of the following bad technical decisions you made at this company? And I think the answer is yes, that needs to be communicated. These were bad decisions. Let's get you learning from these things. Yeah. I can see why that communication would not happen if the manager is not involved in the day-to-day. So the manager probably doesn't know about those bad decisions or what the impact was, but they're in the best position to deliver feedback because of that manager relationship. So Brett's colleagues are probably not going to say,

hey, those were real bad technical decisions and you need to improve. But it's harder for the manager to say that when they're a bit distant. Right. Okay. I think you've got a surefire solution here. Yeah. And if none of that works, you can quit your job before Brett quits his. You just take the spot. Say, oh, sorry, it's full. We hired. The position has been filled. The position has been filled. Now I have two jobs. I've heard so much about that over-employment thing and I've decided to try it.

Hey, Jameson, have you noticed there's a special kind of pain that software teams feel when they get big enough? Pain of open floor plans? No, I'm talking about the pain of owning a huge pile of services, but having no clear ownership. This makes so many routine things harder

than they need to be. Like knowing who's on call, onboarding new hires, finding out who owns what. If you're lucky, you have some spreadsheet or maybe like four spreadsheets that list all the services your teams operate with manager contacts and on-call schedules, but you probably don't even have that. I've definitely felt that pain. Well, this is where Ops Level comes in. Ops Level is a product that replaces that old spreadsheet that no one trusts with an always up-to-date catalog of all your services and teams. And Ops Level takes the friction out of launching new services by providing guardrails that let developers focus on writing code instead of chasing down people and getting approvals. When I worked at Amazon, we had tools like this. I can't

imagine living without them. But small and medium-sized companies, they can't afford to build them. And this is why you need OpsLevel. I've lived without them. It's rough. The Rolodex of people who've worked there a long time is not as scalable as OpsLevel. Go to OpsLevel.com soft skills to solve this pain and learn how ops level makes shipping great software easier end the suffering go to ops level.com soft skills all right should i read our next question yeah go for it this is from an anonymous listener who says i recently did some extensive planning for a feature with a back-end engineer where we negotiated what the graphql api would look like as i was finishing up my feature work i realized that they departed from that plan and didn't tell

me. Now the feature is late. They're having to make adjustments because the departure from the spec made it impossible for the front end to handle the data. I'm having to do more work because they used a completely different architecture than what we discussed. What's even more frustrating is that the end result on the back end is going to be exactly the design that I initially proposed, which is documented, which the back end engineer shot down when I proposed it. I feel angry that they dismissed my technical expertise. This has also eroded my faith in collaborating with this person a retro is coming up how would you approach the retro what outcome do i even want here i don't think more process is going to be helpful since i spent six to eight hours on the planning portion

of this feature i'm starting to wonder if my perception as a primarily front-end engineer prevents the back-end engineers from lending me credibility oh ouch that last sentence was like that was the zinger yeah this is a this is a tricky one hmm so the so the back-end engineer the one that went off the rails from what they had planned is that what i'm hearing i think so i can't quite tell having to make adjustments and then moved it back to the original design they made it impossible for the front end to handle the data but the backend engineer shot down the original design so i can't tell if they they agreed to the original design and then the backend engineer changed their mind later or they just never agreed in the first place but ended up

coming back to the original design oh so okay so it sounds like there was a plan a plan a was rejected by the back end team so then there was a plan b probably a compromise of some kind but no one told the front end that plan b was happening and then when plan b came to light or sorry that plan a was geez this is hard to follow okay i'm gonna i'm just gonna give me a minute to create some uml diagrams i'll be back and we need a conspiracy board with yes string and pins connecting things yes and photos and newspaper clippings exhibit a we see the jira ticket outlining the proposed plan closed the jira ticket dated 1985 this is going to be a big board with a kind of a cobweb yeah we've replaced data structures with cork boards with pins stuck in

them there's a string connecting the jira ticket to a person which is the owner field or something i don't know yeah okay you you gave that more laughs than it was worth david i appreciate that oh boy that made me feel good so i okay here's what i think is going on i'm gonna i'm gonna paint the entire industry with a gigantic brush that's one color across the whole industry engineers don't like talking to people about code and designs they just like writing code and doing designs you know and when you're on your first second iteration of a project and it needs to change again it's exhausting to go back and be like yes i know you've spent hours on this i've spent hours on this we've talked about this but it needs to change again that's friction and

i think a lot of engineers just say i would rather just go do this like it'll be fine we'll work it out and i and i suspect that's what happened here you're saying the backend engineer encountered something that made them think they had to change yeah and then just just did it something whether it was their teammates or whether it was something technical about the design or something about making it more or less effort for them and they just did it and unfortunately in these circumstances the back end always has the power you know because they're like no i'm not going to write the api the way you want it i'm going to write it the way i want it and the front end just kind of has to roll with it because you know what are you going to do build a like a middleware server that just

transforms the API. You know what I was just thinking is there were some really terrible JavaScript frameworks of, I don't know, maybe 10 years ago that came out that essentially exposed the entire database to the front end. You know, it's like, oh, you can write these queries. It'll be so powerful. And I'm like, huh. And you can fire your backend team. Go right around them. And then quickly realize that queries are not free. So we have a retro coming up. You should absolutely talk about this because it if you don't talk about it it will just kind of silently rot yes i think the question is how do you approach it how do you how do you bring it up yes it is valid to feel angry uh that your technical expertise was dismissed it's valid to feel like

if we did it my way we would avoid these problems i am really curious to know what the backend engineer thinks and why they did it that way because they probably have some reason that make sense to them well i mean and if you want to make sure they understand that message one way to do so is to just scream a lot like really loud let that anger just come through what could be improved just let out a primal roar instead of describe what could have gone better in that sprint oh man you know that that just wouldn't come across the same over a zoom call i know people who say in office culture is better they're right you can feel the wind of someone's primal scream on your face vr will never get there yes well okay we're gonna have to take a small

tangent here to think about what could we do to augment the emotional transfer over a remote video call like maybe the breath fan yes yeah it's got a little odor that it can insert into the air to make it yeah smell like human breath yeah maybe the occasional water droplet that's accompanied and to get the real experience um some fraction of those water droplets will get you sick with something. We've seeded these with the common cold. 3% of them. We're really just recreating every aspect of the in-office experience from your home. It'll be great. The end result can be exactly... So I think one way this could go poorly is if you say, I told you so. I had the right idea and you did the dumb wrong thing. And if we had just done

my right smart idea then we would have avoided all this work and that could very well be true but there is a very small chance of that message being received effectively it's just a natural instinct to get defensive and and if you deliver it kind of in an i told you so way it would take a very mature person to not on a good day to not get defensive and and kind of put their shields up and start picking at you and you want to talk through like how you can resolve this not place the blame on this person i don't think that will fix anything yeah how would you approach the retro so i would say i mean i think you can still deliver the message that like i was i was confused why we went with this other design and i feel like if we had gone with my design originally

that i proposed we would have avoided these problems like can you help me understand why why it changed yeah and and i think i think um if you can bring concrete i want to i i'm gonna say the d word data to this conversation everyone's like well i'm data driven it's it's so hard it's like if you bring data to this conversation it can it can not only help the other person see your point of view but it can also also help you quantify your own point of view so like let me explain what i mean by that sometimes we get worked up emotionally because our idea was rejected or someone didn't do something we wanted or some of our some deep human need wasn't met in some way but when you take a step back and think about the team and the business and the outcomes you're

going for you realize it's not that big of a deal but sometimes this the same kind of scenario happens and there's a tangible outcome where you can say look this this has cost us an extra 50 hours of development work on this feature that didn't need to be there because we're doing all these sit-ups and it's and we've already had a few bugs that have come in because the front-end code is so much more complex now all of these things could have been addressed with the design that we proposed and if you just share that now you both have a problem you can attack together instead of just saying i didn't get my way and that makes me feel bad and i want you to validate my feelings instead now you're saying here's the problem this has created let's solve this problem

that's a really good point i think you can also frame the problem not as you dumb person who is wrong didn't listen to me smart person who is right they change the design without talking to you and that could be that could be kind of the crux of the problem like some communication was missed understanding was not shared how can we avoid this kind of miscommunication in the future and make it less about like you were wrong because you're going to be wrong sometimes, right? You're going to have ideas that are worse and make it more about collaborating

and being on, I'm trying, it's happening. I'm saying more business cliches as I get older. And I just- Why is that? Is it because they're good? It's like gravity. It just like pulls me. No, they're not.

Are you just pattern matching the words you hear? That might be it. but then who who's at the center of it creating those patterns it's culture there's someone deliberately saying this is how we should communicate and i will model that behavior it's just a there's no cabal controlling the business lingo it's it's just a it's a mob it's emergent yeah i i was gonna say on the same page and and i said those words but i'm not saying not saying them let's come up with a different metaphor that means exactly the same thing but isn't business lingo like we're wearing the same pair of pants wearing wearing the same pair of

pants at the same time it's really crowded or they're gigantic pants and each of you are in one leg you're just like hopping taking turns hopping yeah it does take a lot of coordination by the way you want to be wearing the same pair of gigantic pants as this person how can we avoid wearing different pairs of pants or both being in the same leg how can we hop in such a cadence that we actually mimic walking i mean you could talk about potato sack races those are probably underused as common business metaphors that's a good idea you know we have to do we have to branch out the sports metaphors are too mainstream baseball and football no it's got to be where are the curling metaphors right but the biathlon metaphors like look we just really need to

smooth this ice with our brooms in synchrony we just really need to slow down and take a deep breath after we have skied 10 miles before we take this important shot yes with a bb gun i don't know anything about biathlon i do know that there was someone who got caught doping in curling which is really yeah oh my goodness i've never seen a broom move so fast do you see the way that their traps bulge as they scrub back and forth that can't be natural yeah this is helping yeah we're helping at this point i actually don't remember the question if you focus more on not that i was right and you were wrong but that i thought we had an agreement and we diverged from that agreement

without without communicating it clearly yeah and that's that's a that's a kind of a different track than i was proposing but i kind of like it you know you're essentially calling out that hey you you went off off plan and now i can't trust you in maybe lighter words yeah and that one also is broader it applies even if say say in some world where truth is absolute and you can say their implementation was different but was right just the fact that it was different from what you agreed on would have caused problems yeah even if it was better yeah even if it was better or something so although i will say if it was better you can earn a lot of trust by saying that in a retrospective as well you could say i see that you've deviated from the plan we agreed on i like

this new plan good job and i think that would win you points in their minds but it might also give them license to cut you out of every conversation in the future because they know you're a people pleaser in a pushover they didn't like the plan so you shouldn't say that true i was thinking of an alternate universe but yes okay your plan has some fascinating qualities that really led me to have good thoughts and pondering sessions yeah what's what's the most backhanded fuzzy compliment you can give their plan yeah like you've really explored a thorough set of failure modes here and brought to light problems that i didn't even know existed so this is great you really reminded me of all the problems that we solved two decades ago and why we why we put these solutions in place

and thank you for great history lesson raising that historical context of why this is a horrible way to do things you know the memory of the software industry is too short and i appreciate you yes reaching back not just for the successes but for the failures that's so painfully painfully passive-aggressive i kind of love it yeah i think you should absolutely bring it up in the retro and you should try to figure out why they did what they did and why it seemed right at the time just like you would do if there was an outage right someone hit the button that destroyed everything why did they think that was a good idea why did that seem like the right thing to do and how could you make that less seem

like the right thing to do what is that called rational operator theory i think you're assuming people or local rationality that's what it is you're assuming people are acting rationally in the context that they're they're they're working in like they're trying to do the right thing right usually not trying to do the wrong dumb thing yeah like i say to my team often like nobody wakes up in the morning and says you know what i'm gonna do today i'm gonna take down prod write a few bugs cause some issues like no one does that and it's almost always some missing piece of context and i'm sure that's what that's probably what's happening here could have been an innocent mistake but you know time to make sure they never ever ever cross you ever again

you know i actually say a subset of what you just said every morning to my team i say i'm gonna cause a bunch of bugs and take down prod and i don't i admit all the nobody ever says that parts of it and just say the middle part okay and how's that working keep some on their toes i think we've answered the question i think so too have we yeah i think so okay well good luck please let us know how it goes if you have any feedback or if you want to just make up a story i mean we won't know right you could yeah you could spin a tale this could lead to exploring the stars and if it's a good read we'll read it okay this is the first step of your space opera yes coming to the retro what can people do if they want their own questions answered go to

softskills.audio and click the ask a question button thank you so much to everyone who submits questions each week we love love your questions also as a reminder if you've submitted a question in the past and we gave an answer and you took our advice and disaster ensued we would like to hear about it you can use that same form to tell us your story we reserve the right to totally change your story to make it sound like we were totally correct yeah no yeah we'd love to hear about that we would we would read the truth we want people to know just like you said in the retro, you admit the idea was good. If we admit that our advice was bad, it'll buy us more credibility, paradoxically. That's right. And with that, I think we're done. We'll catch you next week.