Soft Skills Engineering - Episode 299: Neophyte estimates and forced framework

Episode Date: April 11, 2022

In this episode, Dave and Jamison answer these questions: I’m a new team leader running a new project and when asked for a delivery date I gave my best guess (noob!). That date is at hand, our project is not. I gave a new delivery date and you guessed it, it’s later than the date I said way back when. I presented this new date to my boss, but he wants us to deploy what we have now… even though if we deployed what we have now the business’s cash flow would ignite tearing our collective hopes and dreams asunder. I told him this, in those words, and he said (with a knowing look) “ahhh, you’ve got to play the game, you have a reputation to protect”. I said I’d prefer a reputation of honesty, accuracy and improvement. He said he was talking about his reputation. His other teams consistently miss delivery dates, so I’d guess he has a reputation of missing delivery dates. I’d love to share my more accurate date, but that now feels like going behind his back, but if I don’t go behind his back - I’m going to get stabbed in my front. For now I’ve settled on putting my new date in confluence so I can use it as a shield when the inquisition comes. Dave, Jamison, what would you do and why? A parallel team has sold our VP on their internal framework, and has the VP convinced all other groups in his org should become dependent on it as a multi-app, multi-platform solution. Their framework is very buggy and they are very slow to acknowledge and fix bugs. They claim that due to the overwhelming amount of users/adopters of their framework, they can’t look at bugs, or that other projects take priority. This blocks our development. No one except them wanted to use their product, and somehow they used forced widespread adoption to avoid responsibility for missing their deadlines. This group has magnificent soft skills that have allowed them to evade being accountable for their issues. This team is a darling to the VP, so they are immune to accepting our feedback for the points I listed in the above question. How can we, who are multiple levels removed from this VP, improve our situation? Our group enjoys working together and on our product, so we don’t want to leave. We just want to find a way to become more tolerant of this other underperforming team. Show Notes https://www.hillelwayne.com/post/we-are-not-special/

it takes more than pressing ctrl c repeatedly to kill a fork bomb and then having to power cycle your computer to be a great engineer this is soft skills engineering episode 299 and i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers about the non-technical stuff that goes into this lovely field that has strange metaphors for names of misbehaving software like fork bomb do you think if you did that in front of someone who wasn't an engineer they would think more of you or less of you if i did what if you if you fork bombed yourself on accident and then had to shut your computer off to fix it would they think more or less than me yeah i feel like they would they

would imagine some arcane sorcery had happened and you were you were wrestling with it i'm like frantically typing yeah instead of like you typed too many curly braces in your bash script or something i think they would think oh you turn it off and on again too yeah anytime something breaks a spell so powerful even the wisest of magicians use it it is a powerful spell it's amazing how bad we are it's amazing how bad software is at accumulating correct state over time you know it's so applicable at every level of abstraction too you can always count on good old turn it off and turn it on again in fact well i don't want to get too deep down this rat hole but i've even started i think there

are what is it airline it's like the entire programming language is based on this whole concept of turn it off and back on again oh that's true you're right yeah let it crash is really turn it off and on again and a lot of modern web services are built on this idea of like we have processes they handle requests but they only handle 25 before we turn them off and replace them with new ones it's like the ultimate memory leak fix yeah that was the standard rails technique like a decade ago longer than that actually a while ago yeah still is i think is it i mean i think well i don't know about rail the rails community as a whole but yeah like in python and ruby like all the tools i've seen they all have like a setting where you can say kill this process

after x number of requests but that's not what this is about no no not at all this episode is sponsored by ops level ops level makes shipping great software easier and you will hear more about them later so they i think what they specialize in is turning it off and on again as a service yeah turning it off and on again as a service t-i-o-o-a-a-s-t-u-s perfect it's like sass okay can i uh thank our wonderful patrons please we have one-time shout outs for owen shardle and help me i'm stuck in vim and weekly shout outs for craig motlin rum and code i love mavis the stochastic parrot alice joe jost or jost sorry sorry alice andrew pollock the yeet your job podcast ian walter arun duna patron.com.au we're hiring

ira chan monkey face emoji jonathan king testing is documenting.org rm rf prod ragnar artisan timmy garabrant nick hathaway travis sanders brayden canes john grant nick kantor and philip john basile if you would like to join this list of people and have us say whatever you want us to say within safe for work limits you can go to soft skills.audio and click the support us on patreon button if you give enough to make a material impact into jameson's yacht payment we will say your name on the air every week this is my yacht savings account you haven't bought it yet not yet still deciding i think one of these was trying to check to see

if there's a shell injection vulnerability in our podcast yeah yeah if we promise to copy and paste all of these into our terminal will you contribute more money that's yeah that's the unobtainium yeah for a million dollars i'll run whatever command you want yeah i think there's some nefarious actors who would love to talk to you then yes all right all right i'm gonna read our first question do it this is from an anonymous listener who says i'm a new team leader running a new project and when asked for a delivery date i gave my best guess noob that date is at hand our project is not i gave a new delivery date and you guessed it it's later than the date i said way back when i presented this new date to my boss

but he wants us to deploy what we have now even though if we deployed what we have now the business's cash flow would ignite tearing our collective hopes and dreams asunder i've told him this in those words and he said with a knowing look ah you've got to play the game you have a reputation to protect oh boy i said i prefer a reputation of honesty accuracy and improvement he said he was talking about his reputation his other teams consistently miss delivery dates so i'd guess he has a reputation of missing delivery dates it's my legacy yeah i'd love to share my more accurate date but that now feels like going behind his back

but if i don't go behind his back i'm going to get stabbed in my front for now i've settled on putting my new date in confluence so that i can use it as a shield when the inquisition comes dave jameson what would you do and why oh man this is one of the better better written questions that i've seen in a while very well done it's snappy uh-huh well you don't want to go behind his back and you put it in confluence which feels like the right thing to do because no one will ever see it right you just type it in there you've hidden it effectively it's a great way to hide information good solution yeah but you keep a reference to it so that you can secretly pull it out in the future which i think is what the question asker was referring to

it's ready to go when the inquisition comes what you really need to do so you can add a view tracking widget onto confluence pages i think maybe this is an add-on either way you can do that and then you expand it to see a list of all the people who have viewed the document and how many times and then you need to do like a cross-site request forgery attack on your boss or something to get his name to show up in that list so then you can say see you saw this date you looked at it and you didn't say anything you approved it implicitly yeah so i think what you're saying is you've got to move to blame deflection mode here where instead of now proactively conveying to the business the things that are coming up you now need to protect your job and make sure that your

boss's job assumes all the risk you protect your job with your boss's job right you've heard of yeah you've heard of human shields this is like a yes a role shield i guess i don't know i just feel like this is a giant company if it's not then it's a really bad small company like you have to play the game with like 20 people then then wow you've achieved something that usually takes thousands of people to achieve yeah another option is you could just ship it i mean just do what your boss said you know document like okay my boss decided to ship this in its current state and then watch the business go up in flames and i guess you'll all be looking for new jobs yeah i'm gonna be really brave here and give the the meta advice to quit this job

and shocker maybe you can quit this job and get another job at the same company like if it's a big company work with a different manager that's what i'm saying this does not seem like a healthy work environment if there is that much political pressure around estimates also classic evil mistake of asking for an estimate and then turning it into a deadline you were asked for a delivery date you gave your best guess now it's a deadline that you have missed or at risk of missing and and you give an estimate when you know the very least you'll ever know about a project i would expect someone asking for an estimate to be very explicit about whether they are asking for an estimate or giving a deadline of when this has to be done by or

turning your estimate into a deadline yeah like how if i answer your question how and when will this information be used against me yeah yeah and used against you is the right way to think about it because you are in a in a stabby environment yeah stabbed in the front yeah oh my goodness yeah i mean so let me put on my another hat here which is the let's try to salvage the situation hat i wonder if there's some way you can do something to your code right now that will make it deliver some value and minimal risk and still ship it and let your boss say that your boss hit the deadline you know like a lot of times there's only really two levers you can pull when it comes to this you can either ask for more time well three levers ask for more people or reduce scope

you know there's not there's not a lot of other places you can go to change these things and it's like in this case maybe you can reduce scope and negotiate with your boss and say okay i know we offered you know i know we promised to deliver four things but we can deliver these two safely today. Would you rather take these two delivered today or take the four delivered in a month? Or take the two today and two more in a month? And so I think if you do that, it's a little different than just saying... I guess what I'm saying is there might be a false dichotomy here, where on the one hand, your boss thinks we have to ship everything. And on the other hand, you think we have to ship nothing. But maybe there's something in the middle.

the operative word i'm seeing is now which maybe maybe now is not literally today but it could mean the dead estimate is is fixed and it's tomorrow did you say dead estimate yeah that's a good one that is a good one i need to go trademark that or copyright it or protect it in some way google does not know about this word let's see that word is licensed agpl and so if you say it i own the other words that you say nice work that is a good word no literally google does not know this word jameson you just i gotta i gotta get that seo juice going on it i forgot what i was gonna say because i became so proud of myself i mean it's possible that they're that even taking what you have and getting it into something

shippable will extend beyond the dead estimate but maybe that's a better i mean that that could still be a better case than than just nothing there is a valuable lesson in here as well which is that uh the earlier you can call out delays the better because if you had called out this delay or this possibility of delay a month ago then presumably your boss could have told you a month ago too bad it's an it's a deadline now and we need to hit it so cut scope now so that you can hit this avoiding giving notice that a project is late is a technique near and dear to my heart that i i'm trying to let go of but it's it's really hard but it might have it might have helped avoid stabbing yeah it's good stab insurance yes all right well what do you think

did we answer it yeah i i just will reiterate it doesn't there doesn't feel like a productive healthy relationship here between your boss and you because even if you do use them as a as a career shield you you do kind of have to out them as uh it's their fault like there's there's a lot of blame implicit in the framing of this question it's gonna be somebody's fault right and it's not your fault it's your boss's fault and and that means someone is looking to assign blame or that's kind of the culture you have, which doesn't feel great. That feels not great. I also like what you said, Jameson, about how at the point in time when developers give estimates,

they know the least about the project. And good project managers know that as the project progresses, you should check in to see what was invalid about the assumptions made that led to the initial estimate and find out if a revised estimate is in order. And guess what? It is. It always is. a good a friend of mine a good co-worker of mine calls them guesses and says i don't like to

emphasize the value of estimation because it's like telling someone that they're really good at guessing it's like great job you guessed really well and remember that software engineering this is not a repetitive craft we're it's not like you're a home builder constructing the same house 12 times and you're like oh why did the 12th house take a little longer you know it's like no this this is like designing a new house or it's like it's not like shipping 100 cars on the assembly line it's like designing a new assembly line you know these are things that are have inherent high degrees of unknown to them and so estimates have necessarily high low accuracy at the beginning so this might be an opportunity for you and your boss to sit down and say

i would like to establish some tenets in our working relationship that will guide us And I think for future projects, we need to do something about our estimation to make sure that as we're planning things, we can do continuous planning and not be beholden to bad information that is old six months from now. I'm going to link you to a contrarian take about this comparison to other kinds of engineering, which basically argues that software developers are wrong in their conception of other fields and how certain they are and how repeatable they are. it starts with this quote about no one ever had to think about moving a starting or ending point of the bridge midway through construction and then civil engineer said i have to move a bridge i had to move a bridge yeah i've read that article i think i know what you're talking about it's excellent oh yeah it's really good but your boss doesn't know this because they're probably not in touch with with great software writing so yeah like like jameson is yes if not the producer

have said great writing. No, I am not. 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 Ops Level. I've lived without them. It's rough. The Rolodex of people who've worked there a long time is not as scalable as Ops Level. Go to opslevel.com slash soft skills to solve this pain and learn how Ops Level makes shipping great software easier. End the suffering. Go to opslevel.com slash soft skills.

Dave, do you want to read our next question? Yes. This comes from an anonymous listener who says, A parallel team has sold our VP on their internal framework and has the VP convinced all other groups in his org should become dependent on it as a multi-app, multi-platform solution. The framework is very buggy, and they are very slow to acknowledge and fix bugs. They claim that due to the overwhelming amount of users and adopters of their framework, they can't look at bugs or that other projects take priority. This blocks our development. No one except them wanted to use their product, and somehow they used forced, widespread adoption to avoid responsibility for missing their deadlines.

This group has magnificent soft skills that have allowed them to evade being accountable for their issues. Ooh, I like that. This team is a darling to the VP, so they are immune to accepting our feedback for the points I listed in the above question. Ah, listeners of the show. Clearly. Clearly. how are we who are multiple levels removed from this vp how can we who are multiple levels removed from this vp improve our situation our group enjoys working together and on our product so

we don't want to leave we just want to find a way to become more tolerant of this other underperforming team this is gnarly proof that soft skills trump hard skills i wonder what it means that they have magnificent soft skills i know i felt like that was kind of a backhanded compliment like they're very sly and manipulative yeah which i guess are soft skills yeah the dark side of the soft skills they're very good at mirroring a thing where you you pose kind of like someone else poses and then supposedly you can subtly influence what they do is that one of those decredited psychology things oh probably got squashed by the replication crisis yeah i choose not to look it up

so shared abstractions are great if they're great i can see the motivation behind this presumably there are some common features or functionality that this provides and it could help people go faster but they always require some amount of kind of squeezing your problem to fit them and it's way harder to build an abstraction than to build a thing that solves the problem without making it generic so this kind of feels like the default outcome to me i feel like it's it seems less likely that an internal framework would be amazing and everyone would love it yeah although actually i worked at a place that had a really good it wasn't really in a framework it was it was a kind of kubernetes based platform but it was really good the team

was amazing and that was part of it and it sounds like this team is not amazing yeah yeah and boy does it take special skills to create a useful framework i mean it is hard that's next level yeah so i assume this is there there's some blame trickling down to the to the team that the question asker is on because they're not moving quickly or not getting a project done or something or maybe they're just frustrated by it what if you just don't you don't want just don't use the framework is the vp gonna review your code oh right yeah that sounds like something that will eventually get come back to you you know yeah i thought we mandated that all teams must use this framework oh i didn't i didn't see that i must have been out for that newsletter maybe your

communication skills are a little lacking yeah good leaders repeat themselves yeah i didn't hear you repeat that enough i only heard it once so i didn't do it i'm gonna file that one away good leaders repeat themselves and you only said it once therefore no responsibility this sounds to me like a communication translation problem that your team is suffering in ways that are not visible to the people making decisions about this framework, at least this, maybe this VP, maybe this team's lead. And here's what I know in business, especially in groups in business, in organizations, corporate organizations, where there's, you know, a good number of people, like 10 plus people, the visible problems get solved. The invisible

problems get ignored. And so if I were you, I would try to find ways to make this problem visible. And the first way you can do that is by documenting the problems that your team is having. And the best documentation on this kind of problem has numbers in it. And the best numbers are the ones that turn into dollar signs. So if you can show how much money this company is wasting or losing because of choices made in this framework and they're in attention to your problems, you will have a better chance of getting these things the attention that you want them to have. There is an alternative outcome where you make the business or someone in the business aware that that's the cost, but the cost is still worth it. You mentioned other projects are taking priority and maybe those projects really do take priority,

but if you can write down somewhere, it is causing this much dollar loss in this area to not focus on this problem. Then hopefully someone can look at those two projects and see is the number bigger on one side or the other and make sure like, it seems like we're doing the right thing. Yes. Yeah.

It's very possible that this could be good for a really large organization and really bad for some individual teams, which is a thing that can happen at giant orgs. Yes, absolutely. So document this, who do you give it to? Do you send an anonymous email to the VP? An open letter to the CEO. I think you got to work your way up the chain here.

So now you've got kind of what I call a socialization problem to solve, which is who are the people that need to know? And in what order do they need to know it? Who are the people that are likely to be a amplifier for your voice? you know because you you kind of i don't want to use a virus metaphor but i had this idea of a virus spreading and when it infects the right people but a good one yes it's a it's a happy

virus that makes everyone's life better by infecting you but yeah if you get if you get the right people involved i would start with your boss and then get your boss's take on where this needs to go in the organization to actually affect change and your boss will also give you a good a good gut check on whether this is even an idea that could possibly succeed you know yeah there is going to be a lot of information squishing or compression in communicating this too like i feel like the amount of information that travels up a layer is is going to be like log of the amount of information below the layer or something like that so if the vp is several layers removed from you you need to give enough information that by the time the vp hears it they hear at

least a sentence of like this team is late because of this other thing so don't be surprised if you have to work really hard to get that message communicated all the way up yeah it might be repeating yourself to your boss nagging them maybe enlisting other other people without going behind your boss's back but but just kind of yeah like you said socializing that knowledge more widely maybe there's some trusted architect role or something that isn't really in the chain but is influential but the more you talk about this the better i think it will be with one caveat which is you seem very frustrated or or the question reads to me as someone pretty frustrated and making this other team defensive by by telling them they're bad at their jobs and

their framework is terrible feels unlikely to improve things if they're the darling of the vp you're probably not going to either way right regardless of what kind of what's the word for this top cover that they have telling them they're bad at their jobs is probably not the way to get what you want yeah so you just got to bury your frustration deep inside and never never think about it or express it in any way no you need to find ways to communicate this to other people yeah without saying this other team sucks and that's why we're late even if that's true right a lot of times things that are true are not things that should be said to get what you want yeah i mean one other thing you could do is is maybe everyone is in this situation right like maybe

this team is literally prioritizing no one's work or or half the company is is suffering because of this and maybe it's really not globally useful and that would be probably interesting to know so you might want to delicately feel around for feedback from other teams is is this going well in other places and if so what's what's making that happen or is everyone just mad at this thing yeah somebody probably got promoted for this though right building this shared internal framework that everyone uses that sounds very high impact that's what we like to see from our high muckety muck level people they can't take away the promotion though right yeah so so what if it turns out to be bad yeah they already got promoted well i think i'm out

of advice yeah me too these are always tricky situations there's a lot of people involved a lot of perspectives and interesting organizational hierarchy that makes it challenging yeah i'm gonna go back to the beginning and say abstractions are really really hard and yes even in very well used public open source frameworks you still find people just raging against the abstraction so proprietary small team supported ones doesn't surprise me that it can be rough so never do it i guess just give up maybe that's what i'm saying i think yeah with that we're done answering questions yeah i think we did it all right what can people do if they want their own questions answered go to softskills.audio and click the ask a question button fill out the form there and

ask us whatever you like and thank you thank you so much to everyone who does that every week we really appreciate reading all of your questions thank you thank you we will catch you next week