Soft Skills Engineering - Episode 216: One-on-ones and inter-team power struggles

Episode Date: June 29, 2020

In this episode, Dave and Jamison answer these questions: Questions I have a weekly one-on-one with my manager. What should I talk about in them? Things like feedback and career goals become old and repetitive real soon, and I end up discussing current work items. I understand that a one-on-one is my time to ask questions and don’t want it to be a longer daily-standup. My front-end team mates are in a power struggle with my back-end team mates and my design team mates. They’re intentionally making technical decisions that artificially constrain the choices of other teams. For example, design wants a certain interaction for a new feature, and my team says “nope, it can’t work that way, cause the components we built don’t allow that”. Or, they make tickets for the back-end team as in “endpoints have to work this or that way, because our components assume that structure”. This often seems detrimental and confusing to other teams. When I push back against my team they are angry. When I defend my team other people are angry. When I try to strike a compromise I feel gross because I usually think my team is wrong. I’ve tried talking with other teams and managers about the problem. I feel gross about that too because I don’t want to point fingers or throw my team mates under the bus. Where should I even start?

it takes more than arguing over whether a value can be null at runtime to be a great engineer this is soft skills engineering episode 216 i'm your host dave smith i'm your host jamison dance soft skills engineering is a weekly advice podcast for software developers about the non-tech stuff that goes into all the tech stuff i feel like you can have two inverted arguments about this where the people that like dynamic languages are going to say, why would you ever put in all the effort to know whether a value can be null at compile time

when you could just do it at runtime? And then the people who like static languages that don't have null will be like, why would you ever want to find out at runtime if you could know at compile time? And then they both just yell that at each other louder and louder. And then the people that use static languages

that let you have null are in the middle getting yelled at from both sides. Yeah. and then eventually the runtime folks lose out because the creators of their languages admit that this has all been a great mistake i don't know unless rich hickey likes null he likes runtime nulls yeah thanks rich ruining it for everyone really he doesn't like the optional or maybe type oh okay that's maybe a better way to state it okay whatever well i i'm in a different camp which is i like runtime null exceptions when you try to

dereference a null oh you don't even just okay yeah like i optimize to increase that metric is that like asmr for programmers it gives your brain little tingles every time you you know a null pointer exception happens oh look at the shape of that stack trace so comforting oh should i thank our patrons do it all right thank you to the folks who donate at the level where we shout them out every single week thank you to braden canes dennis bogdanov evgeny sladkowski john grant luke bayliss microconfig.io nick hathaway nick kantar alexander philip john basile ryan real mccoy the agile ventures charity sean stanley tactical radio steven arman lee travis vinlock thank you to all those people thank you to everyone who has donated

you make the show happen you help it keep going if you would like to join this group or to support the show or to join our slack team you can go to soft soft skills.audio click support us on patreon any amount greater than zero gets you an invite to the slack team any amount greater than your credit card gets a stern email from your credit card company any amount greater than your credit card limit oh god it gets a stern email from your credit card company so keep it between zero and that and that limit yeah we very nice we should start accepting barter like you could send us some pelts we'll send you a slack invite convert it to yeah slack invite or a shout out hey i am a hundred

percent on board with that if you have something you want to send us in the mail i actually don't care what it is we will definitely give you a slack invitation they don't have our addresses though a problem easily remedied with one email yeah that's true send us an email and i will give you an address to mail some random thing actually it'll probably be someone else's house just for security but when they call me and tell me this weird thing showed up i will give you a slack invite hey this package showed up and i didn't die come pick it up all right let's get into our questions do you want to read our first one dave i sure do okay this comes from a listener named chetan who says i have a weekly one-on-one with my manager what should i talk about in them things

like feedback and career goals become old and repetitive very soon and i end up discussing current work items i understand that one-on-one is my time to ask questions and i don't want it to be longer just a longer daily stand-up i think your instinct is good yeah one-on-ones are for stuff that you don't talk about in other meetings and theoretically you have another venue to talk about status it's sort of like the old joke about those two books what they teach you at harvard business school and what they don't teach you at harvard business school these are two separate books released by two people and together they contain the sum total of human knowledge because it's all the stuff you learn at harvard and all the stuff you can't learn at harvard

yeah what else is there like that's everything it is so you talk about status in status things and you talk about everything else in one-on-ones literally everything yeah it's a long list that means you should never lack for things to talk about that's right what's the problem it's like thermodynamics today we'll be talking about supply lines and logistics in the lord of the rings trilogy and compare and contrast with supply lines and logistics in game of thrones show how much effort tolkien put into it yep and how it adds to the realism of this fantasy novel perfect i mean it's on the list yeah you can't be faulted unless you work at i don't know what kind of startup that would be like a startup that actually where is where you're writing

yeah where your work is about supply line logistics and fantasy novels as a service it's not it's a platform we're going for the platform play that is hilarious yeah what do you talk about so you've you've been on both sides of a bunch of one-on-ones how do you think about it as a manager what are you hoping to get out of a one-on-one i think as a manager i'm hoping to stumble upon information that i would not have access to through any other means. By the way, that's a gigantic slice and event diagram of all the information, but stuff that's relevant and pertinent about your job that I just can't find out through other means. I don't know. I'll tell you what, when I was a manager, I found a

surprisingly high amount of information was about personal struggles or things at work that were causing a person to be less productive than they felt they should be. That was pretty common. I think it was surprising to me personally because I don't like sharing that stuff with my manager yeah it's uncomfortable for me but you're unlikely to hop into a stand-up and say like hey working on this bug ticket and I have depression right so it'll take longer besides that no blockers right I am taking blockers to block the reuptake of serotonin in my brain no work blockers right I have blockers but I'm actually short on blockers which is the problem my prescription lapsed and i didn't get it renewed yeah like no seriously

those are exactly the kinds of topics that come up in one-on-ones but not in stand-up so it's sort of like i don't know is an early warning system the right way to put it you want to know about things so that you can help with them instead of find out when it's too late i would think of it not like an early warning system and more like a spy network where you kind of have agents throughout the company who give you information and you piece all of that information you synthesize all of it and you can start to have a correct mental model of how the organization is working by combining assimilating all these little bits that you gather okay and do you collect that information by walking up to someone

and saying hey what's the scuttlebutt what's the news hey what have you heard i do it by moving the office water cooler to be right next to my desk and then just leaning over to it every time someone comes to get a drink of water and see what they're talking about yeah that was a plot from the office that's right that's exactly right so i feel like i also hear and the question asker mentions explicitly kind of career discussions as a topic but i i hear their complaint which is you can't every single week say my five-year plan is to get promoted three times or something and then right say like now it's my four-year and 51-week plan exactly like you're like okay well another week has elapsed in my five-year plan i am a 0.4 percentage points further along than i was last

week. So we are on track. We're green. No blockers. Exactly. Yeah. So what about on the other side, if you're a person having a one-on-one with a boss, how have you thought about that in the past? Well, I do think there's a place for sharing status depending on the relationship with your boss and the rest of the team. Sometimes your manager may not have visibility into some of the details that are important for them to know about. And so I think it is okay to share status occasionally but if they're like a hands-on manager who's in stand-up commenting after every item and totally up to date then then obviously that doesn't really have a place in your one-on-one there's no point in doing that but yeah i'm okay with status updates especially if it's like

extra sprint you know work that's kind of outside the norm where you're maybe doing some research or forming a working group or you have like extracurricular activity that you've been organizing for the team to do it's great i think it's great to share updates on that stuff yeah so status updates that's what you're saying you give to your boss when you do one-on-ones i'm saying don't be totally shy of doing status updates unless your boss already knows the stuff you're doing if you're just repeating the stuff you said in the presence of your boss during stand-up that's a waste yeah to me i think of the purpose of a one-on-one is to help your boss i don't know who the you is in this situation the the manager and the employee work better

together and that's very vague and broad just like what you said dave about it's everything that isn't status but the way i think about it is sometimes in one-on-ones we won't even talk about work directly if there's nothing pressing work related we'll just sort of get to know each other and chat and that gives a benefit in that we have a closer relationship now and it's easier to talk about things when when stuff comes up so you're sort of like i don't know building your relationship cred with that person yeah so that it's easier to work together later in the future yes you're you're reminding them that you too are a human being exactly feelings and needs so i'm bad at remembering things and i keep notes on one-on-ones so i have a note for each one-on-one that i have

with each person that says sort of what we talked about and if there were any things that we had to do for for either of us from it i also have a kind of top level just sort of stuff about this person so if they talk about their kids i'll put like here's what they said about their kids they have this many kids they're this old just like things to remind me of facts about them to see them as a person not just an employee so you're saying you keep a file on each person i do it's like i'm sure like dentists do this and i don't know those people that you see every once in a while that shouldn't know that your child is going into third grade but somehow do how do you know that it's been like a year since i've been here last congratulations on starting the third grade

yeah it's like borderline creepy yeah you hope it's because they have a file and not because they're following your every move you seem a little too interested in my life yeah in in my mind having a regular one-on-one scheduled with your manager is there because sometimes it will be very helpful and the rest of the time it won't be harmful like sometimes you'll have really important stuff to talk about you'll share really important information or context or learn it sometimes it'll it'll really change things and the rest of the time you're just sort of spending time to get to know that person but it's if if you don't have a regularly scheduled time it's hard for a report to just schedule a meeting with their boss and say like hey this is the

meeting where i tell you i'm getting divorced and that's why i'm having a hard time at work you know like you have to have that cadence and that habit of talking so that when there is something really important to talk about that it's there there are there are habits that that will make it easier to share that information yes interesting so you're saying that all of these seemingly possibly useless meetings are actually preparation for when they're really important i think so i mean the pareto principle probably applies to this like it does to literally everything else i'm gonna horribly butcher it but basically you get 80 of the value from 20 of the of the effort so maybe like most of your one-on-ones are not useful and then a small number of them are very

useful but if you didn't have all of them then you wouldn't get any of that value does that make sense yes i think so i think that makes sense you don't know which 20 are going to be or which anyway whatever i think i got it yeah and honestly i mean your your work is kind of like that too yeah if you had perfect information about what would happen in the future based on the work you were doing i bet most of it would not deliver value but you don't know it so you do a bunch of stuff and then figure out like yeah we were right about this thing so you're probably wrong you're saying that uh if i if we could predict the future a little better we could do one day work weeks i think so yeah probably i suspect there's probably a bunch of people who have

already figured this out and are already doing this yeah if 20 gives 80 of the value i'll just do that 20 yeah exactly yeah okay so i have i have noticed a disconnect between what people think are in their manager's minds and what is important to their manager versus what is actually in their manager's mind and what is important to their manager and i'll get to how this relates to a one-on-one in a second, but typically what I see is people think their manager knows a lot more than they do. First of all, they see more than they actually see. And second of all, they probably have a misplaced set of priorities, meaning that the employee thinks that the manager feels very strongly about subject X, but really it's subject Y. This comes from the fact that

managers and employees work in very different environments and their interactions are limited. so all of that having been said a good thing to do in your one-on-one in my opinion is to ask questions about what's going on in the manager's mind things like how is the team performing how can i help on the team is there anyone that needs my help what do you think are the biggest priorities tell me about what you're thinking about the future of this team where do you see us in a year in two years what are your thoughts on the on the financial prospects of our company in a year or two years. And boy, I mean, there are some managers

who can just fill an entire one-on-one sharing all this information with you, having just seeded them with one or two questions. And I have found those to be very, very valuable. And I take notes and I try to really understand what's going on in my manager's mind. That's interesting. I have a list of one-on-one questions.

So usually I have one or two things. Sometimes I have zero things that I bring to a one-on-one to talk about. And the rest of the time is employee driven. But if the employee doesn't have anything they want to talk about, i have a big old list of questions to ask them and they're sort of the the opposite of what you asked so okay it's it's me asking the employee those questions basically and me trying to get

at what is in their head but i haven't thought about it's weird to say like can i tell you my my long-term plan for the team yeah exactly yeah i think in general the the more the more you bring to it the easier it is for the one-on-one to fulfill that purpose so if you want to know something or want to get something out of it then it's sort of on you to do that yeah cool have we answered the question well i think so but i actually have a question for you first okay where do you see this podcast in a year or two years everywhere i see it on billboards buses written in the sky written in the earth everywhere archaeologists uncovering ancient yeah in the temples we will build as a monument to the podcast yeah perfect now what was this symbol

what what did this square smiley faced god represent with the weird thing sticking out as a reference to our logo if you have not seen it yeah all right now we just got to make it happen and we'll start by answering this next question that's right i read this is from an anonymous listener who says my front-end teammates are in a power struggle with my back-end teammates and my design teammates they're intentionally making technical decisions that artificially constrain the choices of other teams for example design wants a specific interaction for a new feature and my team says nope it can't work that way because the components we built don't allow that or they make tickets for the back-end team that say endpoints have to

work this way or that way because our components assume that structure. This often seems detrimental and confusing to other teams. When I push back against my team, they are angry. When I defend my team, other people are angry. When I try to strike a compromise, I feel gross because I usually think my team is wrong. I've tried talking with other teams and managers about the problem. I feel gross about that too because I don't want to start pointing fingers or throw my teammates under the bus. Where should I even start? I just want to make sure I got this right. Your team is making artificial constraints on other teams when you try to defend them you can't because you know they're wrong but then other teams try to do it to you and you try to compromise but you don't

want to do that because you know they're wrong wait no the other teams i don't think the other team is is imposing these same constraints on them i think the other team is like don't impose constraints and the question asker is saying what if we only impose half the constraints and then everyone gets mad at them oh okay okay so the front end team is imposing all these weird constraints on the back-end team. And the back-end team is saying, look, it doesn't work that way. So I think you should join the back-end team. Oh, you're saying that's your advice to the question asker? Yeah, exactly.

Yeah. Join the sane team that works well together. Yeah. And fights against arbitrary fake constraints. Some of these practices don't look awful in some contexts. So this idea of the front-end team sort of suggesting a structure to the backend team i've seen work pretty well when there are divisions between front end and back end and the front end has to build something they can't just do nothing but they want to assume a certain data structure so they might send that to the backend team and say like hey if can you make it fit this structure and then they build against that that api contract basically but i mean if they can't then the front end team doesn't just cross

their arms and say like well too bad because i already built this code and everybody knows once you build code you can't change it so you have to change your stuff i had a customer when i was in the defense industry years ago who used to say the main difference between software and hardware is that once the software is built you can't change it he was an electrical engineer by trade so you know he really hated software i have seen several there are plenty of software people that hate software too though like a brand for some developers computers were a mistake is that's right a rallying cry yep it is interesting though because the way that i couch this is we have a front-end team who's saying no back-end you need to build this universal general purpose api in a

way that is deeply coupled to my current web framework that i'm probably going to keep for the next six months yeah this is some some background this question is from 2017 so these components are long gone that's right there's no way these components still exist yep that's three years is is javascript years are dog years basically that's 21 years they're like hamster years yeah it does feel like they're sort of running wild a little bit yeah my impression is this person is not the manager of the team because they say teammates it seems like they're a person on the team who's sort of caught in the middle yeah and is trying to resolve things it's like those cowboy standoffs where there's three people with guns all pointed at each other

and they all have shifty eyed looks that keep staring back and forth between each other and this person like crawls underneath one person's leg and stands up in the middle of the circle and it's like what if we all lower our guns and they all point their guns at this person now we agree we'll get this person first and then go back to our standoff yeah that is a very good metaphor i'm sure that happened in the wild west all the time try talking with other teams managers i feel gross because i don't want to start pointing fingers or throw my teammates on the bus yeah i can see that especially if you think they're wrong it would feel weird to go to another team's manager and say hey i'm sorry my team is wrong and bad like i don't know how to

fix it but i recognize they are bad and wrong and do you have any openings on your team yeah yeah this is dysfunctional i mean contracts between teams are are useful and helpful to decouple things but this is not that kind of decoupling contract where you just say here's how we work together and we'll go build off our our separate things to to meet both sides of it this is like top down where the top is literally it's it's like middle out because design is not part of this yeah it's like the front end code dictates both the design and the back end exactly there's this weird middle tier that's throwing the rest of the organization into its orbit so what do you do about it this strikes me as a missing role on this team and that role would be

one of a software architect or a more senior principal or staff engineer whose job it is to review and approve the contracts between systems in this software system and that way both teams would be presenting designs to this more senior role person who holds the role and that person would be like nope that's too coupled or nope that's uh that's a temporary thing and you know we're not going to build our api against this weird little jquery widget that you found and copied and pasted but yeah i mean it kind of strikes me like there's no arbiter here where ties can be broken yeah ideally that's i think you're right when you say an architect or principal engineer that you're saying between the front end and the back end team they're sort of yes involved

in both right that's right someone who hierarchically is responsible for both of these teams yeah i mean that's a pretty common way to handle disagreements between people or groups at the same level as you sort of bubble it up to someone at a level above that can hopefully weigh between the two that's right and and if if you have an established review culture with that person at that higher level then these disagreements usually never even happen because the front-end team would be too embarrassed to put a design in front of that person which is not what's the word help me word i don't know i don't know what you're trying to say it ends with minical let's check google oh wow google doesn't know what i want

it looks like there aren't any great matches for your search okay equanimical yes what does that mean i think it means like fair to both sides yes equanimity yeah equanimical equanimical equanimical equanimical having the property of equanimity how about we say that to be concise yes anyway equanimity that's what we're looking for here is a design that doesn't impose any undue burden on any individual team i'm assuming that doesn't oh no it's what's that it's ecumenical are we reading the same definition right now no it's a different word yeah the one that says of relating to or representing the whole body of churches yeah so that's one there i think this might have a religious background but it

means worldwide or general in extent influence or application this is probably not the right word i didn't know about this word i think equanimical might be wrong too okay we're pivoting this to an entomology show etymology ah i can never remember i can never remember that one either it's etymology etymology oh i was bitten by the dumb joke about how they're almost the same thing nice oh okay i can't remember where we were though the point is we need someone who can arbitrate this kind of stuff and stop one team from acting only in its self-interest and not the self-interest of the group yeah what if it doesn't exist though i mean it sort of seems like it doesn't because then it's you it hasn't happened then it's you congratulations you are

now the principal engineer that's right you must be separate from both teams to judge fairly between them so that's promotion just is is part of it that's right get it and a pay raise yeah so congratulations you did it so it feels gross to talk to the other person's manager and throw your own team under the bus but i think it should be totally great to go talk to your own manager and say i feel like our team is not behaving in a way that serves this company yeah it's not about throwing your team under the bus it's about helping i mean ideally you think of these other teams as sort of your extended team too and they can't really do their job well because because of decisions made on your on the front end team so that's right sort of helping everybody and then

with that conversation with your manager it's time to do a little bit of root cause analysis why is our front end team so dead set on having all the other teams work around them and you know i hate to say this but it could be that your front end team is operating at like the max capacity of their abilities meaning that they're like look i have these components these tools in my toolbox they're the only tools i know and if you build me an api that isn't compatible with these tools i can't build your front end hmm that seems unlikely i feel like i don't know it's hard to know without all the details i mean yeah there is that's like the competency gap but there could also just be kind of a hubris issue where it's like no this is the way i like to build and

therefore you all need to go with it yeah that may be possible as well like they're capable of using other tools but they choose not to it's not bad that the front end influences the back end or the front end influences the design it's bad if it only goes one direction design and front end when it works well always has some healthy back and forth where a designer builds a thing and you say great this will take six months to implement your like 3d whizzing around this virtual world after to reach the email form at the end of the maze ui or whatever or like you didn't put any hover states or error states in or there's always this back and forth and trade-off and and the design rarely ends up exactly like it was in the initial like photoshop mock-ups or

whatever yeah that's pretty common but it's not like the front end says nope here is how it will be and dictates it to the designers or to the back end yeah so that part seems gross they have to listen just as much as they're uh pushing back and then some of their stuff might have to change right and then sometimes the the pushback isn't exactly pushback it's more like helping the other teams understand the cost of their design decisions so for example the design team may want some whiz bang thing and the front end team job is not to just say no but rather explain to the business the cost of this will be x whereas if we do it this other way the cost will be one tenth of x yeah and i've had a i've had a situation like that i remember i was working on a front end

team years ago, and the designer wanted to do this drag and drop UI, which I'm not opposed to on principle, but our UI had major performance problems where, you know, you would do a click and it would take three or four seconds for the UI to respond sometimes. And so I knew that if we wanted to do drag and drop, you couldn't start dragging something and then have the whole UI freeze for three seconds while you're trying to move the item. And so I knew that if we wanted to build the drag and drop, we would first have to invest a lot of effort into optimizing that to get rid of all the lag you know so it's like can't do it not because it's bad but because our ui actually sucks sorry you just contradicted yourself you said your job is to say no it's to

help you understand the costs right you should have said we can do it give me six months to fix the performance problems and then the two days to do drag and drop that's right that's right and a moratorium on new features in that time because every new feature slows down our ui a little bit okay so i think our advice is generally that your heart seems like it's in the right place where there's not enough there's not enough listening on this team and it seems weird and see if you can try and find i don't know someone someone higher up in the in in the org chart to help balance between these concerns or talk to your own manager yeah and also i think there's a culture gap here where uh there's a team acting in its own self-interest and i would call

this an ownership gap the team doesn't feel ownership over the whole problem they only feel ownership over their immediate area of responsibility yeah so you know just just go close that culture gap it should be no problem yeah just change your culture and make it good instead of bad maybe like go get some vinyl lettering and put it on the wall say maybe it says we're all in this together yeah get one of those kitty hang in there posters oh those are culture right yes we haven't talked about ball pits in a long time but that goes a long way towards making your culture good that's drawing a ball pit you can't share a ball pit with someone and not feel like they're on the same team as you you're sharing a ball pit but really

you're sharing human connection that's right all right have we answered the question now i think so good luck yeah good luck sorry as jameson said this was three years old so apologies we don't usually reach this far back but you know these problems are evergreen though that's true it's just that the the components are in a totally new framework now that's right which means that people the back end had to be rewritten a few times since then anyway to accommodate the new the new front end components well we switched front end frameworks so you got to switch back end languages too that's just how it works i don't make the rules even though i did all right what can people do if they want their own questions answered dave go to soft skills.audio

and click ask a question where you can fill out our form with as much or as little information as you like. Thank you so much to everyone who has done that. We will eventually answer them all. We very much appreciate it. If you want to support the show and get an invitation to our Slack community, our cult, uniforms are pending,

then go to support us on Patreon and just contribute a buck. That's all it takes. And we'll send you an invite at the beginning of every month. You said uniforms are pending. While they're pending, we've relaxed the uniform policy to be whatever you have on you at all times. so technically you're always wearing the uniform always because it's it's it's what you have on

or don't that's the uniform yep all right catch you next week