Soft Skills Engineering - Episode 13: Dealing with a 'yes' boss and the difference between contract and permanent positions

Episode Date: May 30, 2016

In episode 13, Jamison and Dave answer these questions: What should you do about a boss, or in my case ‘solution architect’, who won’t push back to the client and just keeps sacrificing quality of the product to push more features out? What’s the difference between contract and permanent positions?

hello everybody and welcome to episode number 13 lucky 13 of the soft skills engineering podcast i'm your host dave smith i am your other host jameson dance i like how you're always the other host that's that's my favorite uh assistant to the host right on well um i have a little joke for you jameson i look forward to these forever you know how you know i'm always finding the word soft all over the place and then thinking about how it relates to soft skills yeah well here's another one and you have to answer the question though okay how is fabric softener like soft skills um are you looking for like a serious answer like is this like an sat fabric softener as is to soft skills as as i don't know cheese is to a hamburger ah yes i think what you're saying

is your soft skills arsenal is not complete without fabric softener yes bingo that's exactly what i that's exactly what i was thinking do you just write down a thing with the word soft and then pretend like it's a joke i'm not going to reveal how i do this the magic the magic is my secret this is some performance so some performance humor we have been getting just an absolute influx of questions from our awesome listeners over the last week or two and we have so many so if we don't get to your question i just want to say don't worry we got it it's in the list and we will eventually get to it but today we've chosen two questions jameson you want to kick us off with our first one so what should you do about a boss or in my case solution architect

who won't push back to the client and just keeps sacrificing quality of the product to push more features out. Well, you have someone who's not pushy, is what I'm hearing. Well, they are because they're pushing features out. They're pushy to the developers, not to the client. Yeah, so in other words,

they say yes to the people with the money and they say no to the developers that they're paying. Yeah. I have a couple of stories about this. One, um, a few, yeah, a while ago, um, I thought I was in this situation and then I, my, my products kind of owner person could not be there in a call with the customer. And so I kind of took their place and I sat in on a call with this customer and it was incredible how pressured I felt to just say yes to stuff. Uh, even though I had been on the other end of this where i felt like okay this person promised all this stuff that it's hard to

do and it's going to mess up the product and it's bad and we shouldn't do it but just sometimes the for me at least the the physical act of like sitting in this call with this customer that's like we need this we're paying you we want it when can it be done there was like this force to draw out two weeks i don't just like draw some date out of my mouth um and i that actually gave me a lot more sympathy for people in this situation because before i was just like they're bad at their jobs but it's it's kind of a hard job to keep people who are paying you happy while also balancing the quality of the product it's not really an answer that's more like yeah some some empathy might help you feel better about this even though it might not change the situation

yeah definitely i've been in that same situation you just want to say yes you know here are the people with the money and it's not even so much that they're throwing money at you but it's like for me it's like they they're showing you their problem and there is a software solution and you're a software developer you know and it's like i can solve this yeah and and it feels good to tell them like yeah we'll do this it'll be done at this time like yeah you feel a little or at least i i feel this little like tempting reward to just like say this and they'll be happy it'll make them happy right now you'll be a hero yeah exactly and then and then all you got to do is just crack the whip and make the developers do it yeah exactly dave i think you talked about how

you have something at that you do at higher view to kind of manage this problem yeah so we have hundreds and hundreds of customers who pay us a lot of money each and um so we have a humble brag about how rich you are humble brag we've got millions of customers who pay us billions of dollars each um it's going pretty well you can say um yep and uh and so we you know and we've been running this business for years now and uh you know every time you add a feature to the product that introduces permanent costs that will never go away that you have to maintain this feature keep it working and consider its relationship to other features forever you know and we'll talk a little bit more about that later but the problem is when you need to make a

change to the code base to continue supporting the growth of the product that a product owner or product manager or customer will never ask you to do. Like, hey, if we upgrade our FUBAR framework from version one to version two, we can get rid of all these bugs and we can remove some legacy code. And it's like, oh, well, a product owner will never ask you to go do that. So we have a parallel roadmap system where on the one hand, we have the product roadmap, which is a traditional list of features that customers want in priority order. And then we have what we call a technical roadmap. And this is a list of things that developers and operations people want in the product that a customer will never ask for. And so when a team is considering building a new feature,

they also have to prioritize that feature against items on the technical roadmap, and they reconcile the two roadmaps against each other, and then decide what to work on. and this helps i think to give visibility to your product owner and in this case the solution architect or salesperson they wouldn't you know they won't be interested in the details of the technical roadmap but just seeing that there are things there that need to be done uh i think will help a lot to just write them down put them in a list make them reconcile them yeah so just just giving some visibility to the fact that there's all this stuff that needs to be done that's kind what you're saying yeah exactly and then we even rank the items with like how likely is this to

cause a outage if we don't do it or how likely is it to cause a bad customer experience or you know what does it do to our quality of life you know and then that's how we prioritize things and putting that kind of uh let's say labels on the items gives great visibility i think interesting um maybe another thing that would help is to kind of define it so to me um When this question talks about a boss or a solution architect, to me that sounds like a product manager. It sounds like they're responsible for talking with the clients, with the customers, and deciding what the right stuff to build on the product is. Oh, also, I want to interrupt there. Sometimes a solution architect can be pretty close to a sales role at some companies.

I've seen that happen. So we could be talking about almost a salesperson here. if your salesperson can commit to engineering deadlines then there are horribly broken things that's that's a pretty deep problem that i think takes a lot of work to resolve i'm going to assume that this is a kind of a product manager person who's kind of responsible for the team uh and is not directly trying to like sell customers by promising features um but um ideally what a product manager should do is they they they have this cohesive idea of a product in their in their head and they take customer feedback and distill it into the product

they're not supposed to be just like a clear i don't know uh glass i don't know they're not supposed to supposed to just pass customer feedback directly through the developers if they meet with a customer and the customer says i need these five things and then they come back and create five tickets and hand them to the to the developers then i feel like they're not really doing their job um but that is a way that a lot of people work right they just give what the customer said to the to the developers um actually i've had an experience working with a product manager like that and it was really hard because um you just felt kind of as a developer you felt kind of jerked around by the customers like they don't know what the right product is they know

what their problems are and they they come with kind of built-in solutions to their own problems like here's my problem and here's what you need to do to fix it when really what we should be doing is identifying their problems and combining them into a well-working well-designed product and and in this case with this product manager they just couldn't do that they couldn't um meet the customer's needs without just directly doing whatever they said and uh they actually ended up being let go because that's such a huge part of what a product manager is supposed to do so i think maybe just knowing that that's not the way things should work might be helpful um that that ideally this person should be distilling feedback and and giving a broad

direction on what the product should be not just telling you hey this customer wants this text field move to the left like here's your ticket to do that yeah exactly i would also say that in this situation um we talked about having empathy for this role but taking that one step further i think it's important to understand the business side of the requests that are coming in maybe this in this case the person passing this uh this request down to the development team has a really strong business incentive to do that like hey this customer is offering us a million dollars and we're going to go out of business next month you know like unless we take this deal and yeah and then suddenly it's like oh well i guess we do just have to do this you know it's

like to stay afloat um and so that's one thing i like as a developer to ask product managers and solution architects it's like tell us the business incentive for doing this feature yeah and and again if you're working with a good team if your product manager is good they'll they'll have a very clear case beyond they just they need this this is what they said definitely and another thing you can do as a developer to communicate in the language of the people who are interfacing with customers is to point out the uh impact to your development velocity and that's an agile term but let's just think of it and let's just think of it as the speed at which you can produce new features that this kind of approach has so for example if you

start having bugs occur in the product at an increasing rate that's making it harder for you to deliver new functionality to the customer you should point this out and say look the rate at which we're going here and we're not pushing back and we're not like considering these different angles on this feature are causing us to introduce bugs into the product that's then making it harder for us to deliver the thing that you want to deliver which is what the client wants so putting that in the language that your product manager or solution architect can understand is really really helpful yep and and that gets back to the business case for it where if you explain like this is going to make it harder later and and then they say well yeah but we're not going to

be alive later unless we do this then right then that's a clear answer right like yeah you do the the ugly hack that makes your code harder to work so that you can survive to clean it up later anything else you want to say about this question i feel like there is but i'm it's it's it's like forming in my mind i will stall by singing the hills are alive with the sound of music oh i like the falsetto thank you okay you have purged my mind i have nothing oh that didn't that didn't like jump start your your your brain into higher levels of thought yeah nope all i've got is mono syllables now nope yeah um oh uh oh yes here here's yes here is what i wanted to say so um sometimes as developers uh we get a little bit over focused

on things that don't actually matter that much to the business but that seem to matter a lot to us like i'll just give a few obvious examples like semicolons you know like let's say you're a javascript developer and you're like well we need semicolons after every statement you know and it's like this is really important to me is it important to the business no um probably not at all and that's just a dumb little example but it's uh i think it's an important thing to point out um that it makes it makes a good example because it's kind of extreme but there's a lot of things just like that in the same vein where it's like oh if we upgrade to version 1.3 then all of our problems will be solved you know or um i wish we could change this hot new framework that just came

out or you know and we spend so much time just kind of um like fretting over these little details that at the end of the day don't actually make that big of a difference to the customer so hopefully you're not on that side of the fence so so how does that relate to this first of all i agree for sure how does that relate to this question well so like let's say the customer is saying i want these features now now now and the and the product manager or solution architect is saying okay i'll just pass them to the dev team and the dev team is saying yeah but how are we going to upgrade our web framework if we you know build these features right now you know like that it's like it depends on what you're pushing back for sure this will really cut into my mario

cart time if i take on this additional work yeah let's hope we can't have that let's hope that's not the case morale will plummet yeah yeah all right so that was a bit of a i kind of feel like that was a wishy-washy answer that we gave uh get get a better product manager that was one of the clear solutions um the other i think your your feedback was was good and also um possibly easier to do which is uh give feedback that this will have a cost and and it'll it'll slow things down in the future and that's definitely going to happen and make sure that that's an explicit trade-off that people are willing to make instead of just just do this faster go okay great i think we answered that one question answered dun dun dun dun eat the sandwich all right do you want

to read the next one sure this next one comes from listener named antonis and he says what's the difference between contract and permanent positions one has a contract and one has a perm is a contract a haircut is that what you're saying yeah it's like a mullet oh i had a contract when i was a little kid then nice i bet it looks awesome on you so i know you have a giant list of stuff do you want to just list them off oh sure dive into interesting ones okay so let's describe let's define what we're talking about first like contract position this is like when a company doesn't really make you a full

time offer of employment instead they give you an agreement where they say we'll pay you x dollars per hour with like a maximum of n hours per week for a term of m months you like all my algebra in there with all my variables yeah i got it i just put one for all of them um and so that that's what it is right it's a it's a uh it's almost like when you contract out work to do like a home improvement you know like i'm going to pay you this many dollars per hour for the job um except it's you know you're a developer and you're doing work for a company writing software so a permanent position is more like we're going to make you a permanent offer of employment, there is no end to this agreement in time that we are

going to agree on right now. But it's also at will, we could fire you anytime. But then there's a ton of differences in what that actually ends up being, even though at the end of the day, you're writing code in both these situations. So contract, you will not have benefits, you will probably have a higher hourly wage, you will probably be the first person to get cut if budgets are limited, because it's much easier to let go of a contractor than it is a full time employee legally and from an hr perspective you'll have more flexibility as a contractor because you can just bail and you don't have to worry about losing benefits because you don't have them you won't you almost definitely won't get stock options or any kind of equity agreement

and i think that's kind of the chore stuff like the housekeeping stuff is there anything else jameson on that list we should add well no i don't think so not from the housekeeping well i don't want to say no because now someone's going to be like you forgot about this and we'll say sure yeah so yes there's more stuff but i can't think of it now okay um to me the biggest difference is in the ownership and and this can be a two-edged sword um if you are a full-time employee you probably feel more uh like commitment to make the product work and more kind of loyalty to the team like you want to you want your team to be successful and you you want of like work hard and that can lead to you kind of bonding more and coming together and it can

also lead to you uh maybe um kind of over exerting yourself a little bit and and um putting a little more faith in this kind of corporate institution that might just fire you at any moment then is often healthy and with a contractor you have the opposite where you can just like it's really nice to be able to say this is someone else's problem and as a contractor you're at like the very far end of that spectrum of this isn't my problem like i write this code that they tell me to write i get paid um and everything else there's a whole company responsible for all that machinery kind of at the end of nothing else there's management which is like everything is your problem there's contractor which is nothing is your problem besides this very specific thing

and then full-time employees kind of in the middle in my mind where you you're invested and you care about what happens so you you kind of want to make your space good for you and good for other people yeah and that can be good and bad it can be nice to not have to worry about a lot of stuff it can also feel a little isolating um that you're not kind of in the trenches with people as much yeah um one interesting thing to talk about might be like career progression as as a contractor versus as a full-time employee oh good question how how does that affect it does that make sense yeah like if someone's looking at your resume and they're like oh you spent the last two years doing contract work versus working for company x as a full-time employee you mean uh yeah well

Also, I mean, sometimes contract work is like you're an employee of a company that contracts you out, too. Oh. I guess we didn't really talk about that. Yeah, like the agency model. Yeah. But just in general, like, it seems like if you're a full-time employee, there's a clear path to advancing your career. Like, you kind of work there for longer. You get more responsibility.

You solve harder problems. You help more people. And that usually leads to, like, raises and more responsibility. if you're a contractor they're not going to be like okay mr i don't know some x number of dollars an hour you design this giant new system that our company depends on and we will reward you handsomely for it it's just like right right you just kind of get stuff thrown over the wall you it's so as far as like managing your career progression as a contractor i think it depends a lot on whether you're self-employed or whether you're working for a staffing agency or uh any

other kind of contracting agency if you're self-employed then it's just totally on you and there's no way a company is ever going to sit down with you and be like, you're such a good contractor. We want to give you a promotion. And it's like, that's not a thing, right? In that world. But in the agency world, your agency management could very well actually have a career plan with you that you're working on. And it could be like, well, you're billing at this rate. We want to get you at a higher rate. We want to make you more valuable to our clients. And they can help you progress and even provide training. Many of those contracting agency companies do that too that's true and and often for some projects the agencies do um it's not just

one person kind of working on another team there's a whole team of people and then someone needs to kind of do the product management or be the tech lead on that team so this is advancement in the agency but say you're just kind of a you're a solo developer on your own doing contracting work yeah what do you what do you do to grow you just say my rate increases by a dollar every week and then yeah i i think that that kind of is uh definitely the most obvious angle where you're like can i get my skills to the point that i can bill at a higher rate um and i think most contractors who want to do that have to change the kind of contracting they're doing because i think the market is pretty fixed about just how much they'll pay a developer to do a certain job

you know you're not going to get a humongous range in there but you know if you can expand your contribution to say well i can also help you consult on you know this process development or organizational design or you know something else that's just it's not just cranking out code by the hour sure and i don't have any first-hand experience with that but that's what i that's what it seems like would be the case um i have a little bit of experience with freelance stuff and i have observed what seems to me to be a larger range in hourly rate rates than in full-time employment as a developer so i i think you're a little bit wrong there which is in in that you can just charge a lot more money than some other people and some people will pay it um okay like

kind of in your industry there there are some outliers but but i would say the salary range for most people is is within like someone making double what someone else makes is about as high as most people get does that make sense so you're saying like the most you could ever expect is like 2x the minimum yeah and in full-time employment at a company um they're they're outliers if you work at some giant tech company in silicon valley and you're responsible for some very valuable piece of technology but it seems like the range isn't that high but i've seen ranges way higher than that in contracting oh interesting 20 bucks an hour to like 300 an hour just for for development work this isn't for like strategy consultant or what anything like that this is you just sit down

and you write code for people what was the differentiator between the 300 and the 20 in your experience um experience of the person doing it uh a lot of it was was it like a niche like this is the only human being who knows this technology in our domain no not quite um they it was more the relationship that they had with their clients cronyism yeah no they were they were experienced and they were talented um but they weren't like what is that i don't know more than 10 times as experienced and talented as the person that charged 20 bucks an hour it was more like they had proven over over time that they were worth that they were worth that to their clients and the clients were paying for certainty basically like yeah so they like

yeah yeah like we'll pay a premium because we know that this person can can deliver it versus we could pay someone a third of that and it'd still be like a lot of money to pay someone but um we might not have as good of a relationship with them let's talk a little bit about comparing a contracting hourly wage to a full-time salaried equivalent hourly wage because i think some people get sticker shock when they're like oh i'm making say sixty thousand dollars a year that equates to about thirty dollars an hour but i see contractors making eighty dollars an hour what the heck you know and like why why is there such a big disparity um it's because you have to pay for everything yourself the the taxes are a lot higher generally you have to pay for your health care all your

retirement stuff all your equipment like there's a lot of overhead beyond the salary that you earn when a company hires you yes and you take on all that overhead yourself it's huge i mean you think you pay a lot of social security if you're a u.s worker your your company pays that and i think more and they play unemployment tax and they pay um oh what's the other one i can't remember anyway oh payroll tax yeah payroll tax and benefits i mean some of these benefits packages can cost twenty to thirty thousand dollars a year uh per employee you know depending on your company and And so it's like, yeah, it makes sense that these wages would be a lot higher for a contractor. Also, I feel stupid that I said that because that's probably the smallest reason.

The main reason is you probably aren't going to bill like, what, 50 hours a week, two weeks vacation, 40 hours, sorry, 50 weeks a year, 40 hours a week is like 2,000 hours a year. And then if you just multiply that number times an hourly rate, it's like, whoa, that's a lot of money even if I do have to pay my own insurance. But you have to factor in the sales time. have to scrounge up clients and that can often be a huge percentage of your time like i've heard people say that if you can bill consistently 20 hours a week that's pretty good if you spend half your time working and then the other half kind of building leads and that'll have uh ups and downs very interesting like six months where you're just working solidly and then you might have a couple months without a lead you're just not making money so yeah yeah that's another part of

it so leaving the money topic for a minute let's talk about mentality because i think as a contractor it's really easy to get into the mentality of get in get paid get out you know it's like i've got a feature to build i'm gonna write the minimal amount of code i'm gonna copy pasta where i need to um i might make a mess of it but at the end of the day it's gonna work and i'm gonna get out and then someone else can deal with the mess later have you seen that in as a mentality i have seen i've worked in code bases that contractors built or worked in and i've seen things that i i could explain by that mentality i don't know exactly what they were thinking but looking at the code it certainly seems like they were just like we get money here it is it's done

like wash our hands of it see ya yeah that that's been my experience too and i think as a contractor some people like that it's like get in get it working get it to the customer boom get paid we're done but some people would rather have more of a long-term vision where you consider the holistic picture of i want to make it work for the customer and i want it to be great for my co-workers and i want it to be good for myself in 12 months when i come back and i have to work on this again you know sure incentives are weird when you're a contractor too though um i feel like with full-time employees you already sometimes encounter this feeling that people have that are like are they are those developers actually doing anything are they just like

screwing around and kind of wasting time on semicolons or are they getting features done and if you're paying someone hourly it seems like that incentive would be even but that's just that chance of suspicion would be even higher because you can just see the ticker go up every hour that a contractor spends yeah and you sign the invoice every two weeks architecture and unit tests and like you know that stuff is good but then you see like it took them twice as long to build it even though it's going to be way easier to maintain so that means it cost me twice as much money and so i i think that might be hard to justify as a contractor sometimes when they're paying for that extra time you're spending to to polish things it could be it could be it's like look

i paid you to build this feature you know but as a contractor that's probably a conversation that a wise contractor would have with the company to say do you want this to be a maintainable long-term thing with tests and you know uh high code quality and documentation or do you want me to just bang this out as fast as possible and i can see companies being on both sides of that fence yeah um i think one more thing i want to say is that often contracting is used as part of the hiring process either like formally or informally um formally some places will say in order to work for us we will have this trial period of two months or whatever where you'll be a contractor and then we'll kind of evaluate it at the end of that and see if we want to hire you full-time or

not and then the informal way is just the higher contractors if they really like a contractor they might talk to them and and see if they're interested in the full-time position so that can definitely happen sometimes and that arrangement is sometimes called temp to perm you've ever heard that that term used uh no there you go there's a word because it reminds me of the hairdo yeah that's right um and then also i want to say that as a full-time permanent employee uh you are much harder to fire than a contractor. You know, the contractor, you can just say, I'm not going to pay this contract anymore. And depending on the terms, you know, you might have like a six month obligation or a one month obligation. But you can just say, I'm not going to pay it anymore,

we're done. But with a full time employee, usually companies go to much greater lengths to make it work out. And I don't know if there's if it's illegal reasons or what, but it is much, much harder. So if you are way more interested in stability than generally, And that's not saying you won't be laid off tomorrow, but generally, a full-time permanent gig is going to be more stable. That's true. And that's another reason for the pay difference. You're giving up some money in return for stability in a lot of cases with full-time. Yep.

Well. I think that's it. I can't imagine that there's any other difference. Yeah. I agree with you. If there are any other differences, the fact that we didn't say them means that the world will change. to conform to what we just said and they will all be eliminated all the differences so true contract permanent question answered we did it we did it gold medal yeah well uh what can people do

if they enjoyed the show and want to hear more you can go over to itunes or i actually don't know where else you can do this but you go to itunes and rate the show and leave a little comment to say what you liked about it and that will greatly help our visibility and or not visibility what's the word it will help our uh our personal brand that's right that's the word it'll help whatever it is we need to help to continue making zero dollars producing this amazing podcast for you so it helps other people find the podcast there you go it shows up higher in in rankings or whatever yeah there's if you use an app that's not itunes or itunes related there's probably some way to rate or recommend stuff i actually use overcast there's a little

star next to each episode i don't know what it does but i assume it does something i don't know what it does but you should definitely tap that star i tap it for episodes of podcasts that i enjoy um if you have feedback on the show on questions or comments that we make or if you want to submit a question for us to answer you can either tweet us or direct message us at softskillseng on Twitter. If you direct message us, we'll kind of assume that you want it kept private unless you explicitly say,

and I'm okay with you sharing your name or whatever. If you just add us on Twitter, we'll assume that it's okay to mention your name unless you say, don't mention my name. But then maybe adding us on Twitter isn't the best way because then other people can see it. But yeah, we'd love to hear your questions or suggestions for the show.

And if we missed something today or said something wrong that you'd like to correct or add, feel free to tweet at us as well and we will mention it in in uh in a future show yep great thanks everybody catch you next week