Soft Skills Engineering - Episode 437: My company canceled all one-on-ones and moving to a single backlog

Episode Date: December 2, 2024

In this episode, Dave and Jamison answer these questions: My company recently eliminated 1:1 meetings between managers and their direct reports. Previously, most people had these meetings every other week, and they were an opportunity to talk about career growth among other engineering things besides current work. They’re claiming the recurring meetings can be replaced with quick, more spontaneous calls when necessary. Although wiping meetings from the calendar does clear up more time to code, as a more junior team member, I’m concerned that this will negatively impact my career growth. It feels like career progression just got a little bit harder. What’s the read here? Is this a red flag? Should I start looking elsewhere? How can I navigate this changing environment and still make sure that I am able to progress my career? A listener named Matt says, I’d really like to move to a single team-dedicated backlog, where we use kanban and have work in progress limits, rather that the heavy release planning fixed-scope current model. I feel we would be more effective as a team that way (I’m one of many team leads in the company). Currently we operate in an agile-ish fashion but ultimately inside a waterfall process, driven from outside the technology team. Although I believe it would be a good thing, I’ve not actually worked in that way. Is it all it’s cracked up to be? Are there any issues of going to that model that I’m not seeing?

it takes more than remembering the null terminator to be a great software engineer xc7 non-printable carrier character period question mark question mark segmentation fault core dumped this is soft skills engineering episode 437 i'm your host dave smith i'm your host jamison dance no way to terminate soft skills engineering is a weekly advice podcast for software developers who want to think about something else besides null terminated strings sometimes my parents listen to this podcast and every once in a while i remember when i say something i just know they will have no idea what it means i think this means you're vulnerable now to some kind of remote code execution i guess that's where i like incept an idea into your

brain and then you think it's your own idea and you do the thing you could put whatever you want after that null term or after the byte where the null terminator should be yeah and i'll just keep reading it i'm gonna i'm gonna inject instructions to do the episode with me okay perfect dave should i thank your patrons please do all right thank you to alexander kuznetkov 10 print lucas morton is cool go to 10 nick molyneux appa 2 appa 2 with little music emoji have you listened no i still haven't okay someday i will it's on will it make you feel better to know that there are much more vital life things that are also on that same list of things i should do along with listen to this song yes i'm not just neglecting you i'm neglecting important stuff

javier gonzalez chewy ted timbrel chicken i like like liver i do meow mix meow mix deliver you must yoda okay nice become a senior engineer.com unsalted french fries are morally objectionable dan from drone to play chase w norton level up your type script with type here.dev never is not just a crater on mars flamingo emoji i like chicken i like liver meow mix meow mix please deliver the the og trash panda kyle kyle boss kent c dodds nevar is not just a planet in the vulcan system jenny kim owen shardle the stochastic parrot helicone.ai best observability tool for ai red panda is best panda typescript is a microsoft conspiracy jonathan king's and i beautiful functional user documentation it takes more than setting a funny name on patreon to make dave and

jameson laugh to be a great engineer the owner of williamangel.net we can't actually say this name out loud travis braden canes john grant joe grosberg if you would like to join this illustrious crew dave don't gloss over this bit maybe it's different go to soft skills audio and cody sale i like how that last one makes cody sale into a verb yes go to cody sale audio and cody sale yeah like it said go cody sale shall i cody sale our first question yes please do okay All right, this comes from an anonymous listener who says, my company recently eliminated one-on-one meetings between managers and their direct reports.

Previously, most people had these meetings every other week and they were an opportunity to talk about career growth among other engineering things besides current work. They're claiming the recurring meetings can be replaced with quick, spontaneous calls when necessary. Although wiping meetings from the calendar does clear up more time to code, as a more junior team member,

i'm concerned that this will negatively impact my career growth it feels like career progression just got a little bit harder what's the read here is this a red flag should i start looking elsewhere how can i navigate this changing environment and still make sure that i am able to progress my career huh quick more spontaneous calls when necessary i mean technically they can be they're not right or they're not wrong and recurring meetings can be replaced i just know they won't be yes it's theoretically possible i mean i feel like the point of one-on-ones is you you explicitly carve out space for them because if you don't it's too easy to just put your head down and grind through the work and you never you have to have this time set aside to step back i mean you

don't have to but it's hard to do it if you don't yes good news your manager has a bunch of time on their calendar now so you should be able to squeeze in a meeting on their calendar maybe you could just uh when necessary which you interpret to mean every two weeks spontaneously schedule a meeting is it a red flag should i start looking i mean i don't think this is a like quit your job red flag it is kind of odd did you see how big this company was oh let me look startup a startup okay i mean maybe they are feeling some kind of crunch and just really want to buckle down and get stuff done i don't know i don't think it's a red flag i do think you're right that career progression maybe got a little bit harder but i i am kind of being serious i think you are too dave

like great schedule the meeting now you schedule it instead of your manager yeah that's all that changed here i think you might also want to talk to your manager specifically about this and you can tell them hey i know we got rid of this requirement to have regular one-on-ones i really find them valuable. And hopefully you can outline some specific ways that you find them valuable. If not, maybe take some time to think of that before you say this. But then, yeah, you can just say, hey, can we just keep doing them? I think so. You know, lately, Jameson, I've been thinking, we've done this podcast for a long time, and we always tend to have a really positive, rosy outlook on things. And we tend not to ascribe nefarious intent. So I'm going to turn over a new

leaf and try to figure out what is the most nefarious motivation for this behavior. And I think I've found it. What is it? Well, companies notice that the more engineers meet with their managers to talk about career progression, eventually that turns into a request for more money. So by eliminating one-on-ones, you will reduce the rate at which people ask for more money. Okay. All we have to do is keep them a junior engineer forever. You know, I feel like you could get a lot worse than that worst case scenario i was gonna say maybe the managers are all dead there's no one left alive to do a one-on-one with yeah this is this kind of goes against the core the core management philosophy tenants i feel like one-on-ones are a are a staple

of what you are supposed to do as an engineering manager so it is a little weird yeah but startups are a place to do weird things and i feel like you can kind of get away with doing things very differently at a startup because you aren't crushed into the same like megacorp shaped mold yeah but i mean what if your manager says no then you have to just be they're they're rigorously scheduled every two weeks but it's it changes the the hour of the day is spontaneous maybe it's first thing in the morning one week and then the next time it's oh it's 12 15 time for a spontaneous every two weeks check-in it's every two weeks plus one hour from the previous meeting i feel like you could also layer some general one-on-one advice on top of this which i think

is probably more important if you are trying to make a special exception because if one-on-ones are just an expectation a thing your company does your management does then even if you aren't super prepared, they sort of just keep happening. But if you're trying to keep them happening, despite a push to not have them happen, I think you probably need to be a little bit more prepared for them. And by prepared, I mean, you should have something to talk about. You should have a question you want to bring up. You should have a discussion topic, something you've been thinking about. If you just show up every two weeks and you think, this will help my career progression because I'm getting more face time with my boss. And surely we talk about good stuff.

It'll be less useful than if you think about what you want to get out of this meeting and how you can kind of plan and set aside questions and throw stuff on an agenda ahead of time. I think that's generally pretty good advice for one-on-ones, but it's more important if it's a special secret one-on-one. Yeah. I was thinking you could have some fun with this and set up a little like, write a cron job that runs every other monday morning and schedules a one-on-one for a random time when your boss shows available on the calendar using like i'm just going to assume you're on google

google calendar here and just use the google calendar api to find a time that could be so cool it's actually really fun to do little integrations like that and then when your manager says hey what have you been working on lately you get to say hey good news i've had this cool idea instead of all the other stuff I'm supposed to work on. I found a way to get around the restriction. I would like to know if I were in your shoes, I would like to know where this came from and how your manager feels about it. Because if they think, whatever, this is dumb. I like one-on-ones. I think they're useful, but so it goes. That's a very different situation than if your manager is pushing for it. And if they hate doing one-on-ones and think they're

not a good use of their time i don't know i don't have any more thoughts about this right now do you have more thoughts i don't think so i i think well i will say this at the early part of my career the concept of a management one-on-one i had never heard of it and i probably had my first management one-on-one maybe like 10 years into my career it was like fine i don't know what else to say about it i i think some of it is a little bit over you survived yeah like i made it i'm okay my career so you're dressed yeah your point is like you're not just strictly doomed if you don't have one-on-ones yeah that's a good point actually i i didn't have them either really i i didn't have i certainly didn't have regular ones i would have occasional check-ins and since they were ad hoc

and spontaneous when necessary like the question describes i always just assumed i was getting fired yeah true that's kind of how i was too unless it was right around my anniversary time or the like annual review time frame you know then i knew to expect something from my boss otherwise never really heard from them which was that's kind of awesome perfect time to get fired before you get your annual raise and cost slightly more money yes exactly yeah that is i didn't really talk about that part i guess you can think about other ways to do career progression stuff if you doing it one-on-ones. Yeah. Or, I mean, listen, early career progression is kind of like not that complicated. Just do good work. Work hard. I guess you want to check in and know how

are you doing. But it's not like, I don't know, the more senior you get, the more complex, the more moving parts, the more things you need to consider in your career progression. Like, you know, which organizations do I need to be influencing more? What are some of the things that are not on my radar that I need to be considering? And as someone starting out as a software developer, it's kind of like do tickets faster. You know, like that's kind of the main thing. I'm talking like super junior, like right out of school, like first job, first quote, real job. Yeah. And if you do that really well, your career will progress very nicely at the beginning, assuming you're in a decent organization. There I go once again, assuming like a rosy outlook on

life. Even with the absence of one-on-ones, you can still schedule a meeting with your manager is saying hey i would like to be promoted what can i do you just don't have a regular it's not already scheduled for you so i feel like you can still kind of work on that stuff and check in yeah i agree i'm not saying to like avoid your manager and don't do one-on-ones i'm not saying that for sure and i'm also not accusing you of accusing me of saying that but i am saying that in the absence of those things you'll be fine and it is still worthwhile probably to check in every once in a while and say how am i doing how's my performance how can i improve you know what It's hard to tell a lot of change in two weeks, though.

Yeah, exactly. If you're checking in on your career every two weeks, I don't know, keep learning the code base more. Yeah. What do I tell you? I don't know. You need time to accumulate examples of things that you've done or opportunities for improvement or themes to emerge in your work.

When I meet with my people, I certainly don't talk about career stuff every week or two. And it's probably more like a few times a year, really. and honestly i want people really focused like on my team really focused on the work to be done like that's the main thing we have you here for if if we're spending an hour every two weeks talking about career progression i think now i'd rather i'd probably rather have you working on the work that we pay you to do for most of that time yeah and then every few months we can check in and say all right is your career pointing in a direction you want because there is a value exchange right like it's not just money for service right like we come to work to to get

fulfillment to grow and to position ourselves for the next step in our career that's going to be even better. And I'm under no illusion that the team members who join my team are going to be with my team for life. I mean, I won't even be with my team for life. So I understand we need to help set them up for the next step in their career. And one way to do that is to help them accumulate valuable experiences that look great on a resume. And yeah, in a few years, that might mean that they are on to the next thing and they're finding an even better place to work that fits their needs better and gives them more fulfillment and gives them exposure to new ideas. And that's great. I'm super happy about that. And so we do need to kind of help people

along that way so that they feel like they're getting their money's worth, I guess their time's worth out of their profession. And that's a great thing to do, but not every two weeks. You know how pharaohs used to be buried with their servants and their family members and stuff? Yeah. And they would like murder the servants at the time of the pharaoh's death. So you said you're not going to be at this company until you die. I feel like it would be interesting to make an acquisition more like a pharaoh's death right so like you bury the co-founders with all their employees in a giant pyramid made out of money or something made out of the venture capital and then it is yeah then it is it is until you die you get

acquired the company dies and you do too but you proceed to the after life i don't know anything about egyptian mythology there's something there i think all right surely we we have answered the question. I think so. Shall I read our next question? I was hoping you would. This is from a listener, Matt, who says, I'd really like to move to a single team dedicated backlog where we use Kanban. Kanban? How do you say that? Kanban? It's pronounced scrum. However you say it, it's not the way I say it. Okay. Where we use Kanban and have work in progress limits rather than the heavy release planning fixed scope current model. I feel we would be more effective as a team that way i'm one of many team leads at the company currently we operate in an agile-ish fashion

but ultimately inside a waterfall process driven from outside the technology team although i believe it would be a good thing i've not actually worked in this way is it all it's cracked up to be are there any issues in going to that model that i'm not seeing nope it should be no issues at all go ahead and make the change yeah this is an interesting question i can see why it would feel better on the team to work that way and the agile-ish inside of a waterfall is sounds very familiar also i feel like that can be that criticism can i'm i'm not saying it's what you're doing here necessarily. But sometimes that criticism can be overused, right? Like anytime you do any kind of planning or anytime you have a project that like moves through multiple

phases, someone can point at that and say, ah, it's waterfall. And then that means like, ah, it's bad. We're doing it wrong. But it is nice sometimes to plan stuff and you're always kind of mixing things in a little bit, but some upfront planning is helpful. I don't know. I mean, i think it sounds pretty good to just only focus on one thing don't think about anything else in the future and if someone comes to you and says how is this going to work with the broader system you say sorry that's not at the top of my kanban list right now it's great all you have to do is turn the kanban board sideways and then the tickets flow downward through the waterfall and then i don't know there's probably more to this metaphor the pms

are like the bears trying to fish salmon out of the stream at the top or something yes yes i was trying to think of a good waterfall metaphor like what happens when you try to insert a waterfall incompatible process into a waterfall process probably goes fine there's like a pipe somewhere that yeah i don't know work stream aren't those a thing in kanban i've never worked in a formal kanban place what was i going to say something super important and yeah and wise agile fashion inside a waterfall process driven from outside the technology team okay if you want to do this you need to find out what outcomes is the business getting from the current process and how do you still preserve those outcomes using this new process and i don't know what those are because

i'm not you also this question is from 2017 i just found a super old one for fun yeah so you're probably not you anymore but um one of the main things that draws companies towards this big kind of release focused project focused planning model is planning they want to know when a thing is going to be done they want to plan some kind of marketing effort around it or coordinate between teams and say like, this project to add this new product line, here's the status of it. Here's how it's tracking towards completion. Here's when we think it will be done. And that's hard in any process. But at least if you say, if you look at a project and plan around a project, it just like feels like it should be better than if you take a big blob of vaguely organized work and kind of

smoothly flow through it if the answer to someone who pays you a lot of money to work when they ask you hey when when is this going to be done is like i don't know we don't work that way then you're right you don't work that way anymore it's back to waterfall yeah so so i feel like this is always kind of a challenge for agile ish working styles because you do have to have estimates and timelines to coordinate externally and you kind of just have to squeeze them into this fuzzy yeah process that is not not focused on those and that problem applies both to scrum and kanban yeah i mean so i don't know in fact it kind of feels late in this question to be asking this jameson but should we take a minute and describe the difference between kanban and

well i don't even know what to compare it to here because the question asker says a heavy release planning fixed scope current model i don't know should we just go with scrum on that like is that what they're trying to say or like i don't think it's scrum but maybe it's we can probably what's that scale agile framework or something safe yeah i've just seen a lot of diagrams that are intimidating about safe i've also never worked in it actually i think i was supposed to at the megacorp that i worked with i think that somewhere above me in the org chart someone believed we were doing safe oh it did not it it sure did not trickle down to my level though we were not i can tell you confidently my only experience i with safe comes from

the accounts of survivors who talked to me about their experience yeah but yes we should describe stuff do you want to talk about kanban and and scrum sure i I'll take a shot. A Kanban has two features that differentiate it from Scrum. Number one is that each team member only works on one thing at a time. So you're not allowed to have two things in progress at the same time. And number two, you don't estimate and commit to work in units of sprints. In other words, you take a task. When that task is finished, you then move on to the next task but at the start of like a one week or two week sprint period you don't sit down and say these are the following three tasks that i can commit to delivering in the next sprint and that's

i believe at its heart that's pretty much it and that there's probably a thousand agile coaches like screaming at their phone while they commute to work right now but that's what i understand i feel like swim lanes are a thing too but i don't quite understand them it's like well actually i should google this what is a swim lane in kanban it's a horizontal line that helps separate into okay huh just a way to talk about tasks that are somewhere on the board so i think it's a way to say like these project or these these tasks all relate to this theme no matter where they are in progress that's not what i thought it was sounds like a project yeah i use swimlane to mean something else at work what does that mean well

the way i use it at work is like i say look you've got a certain amount of developers who can work on one thing together and so you when you're planning who's going to work on what i kind of lay them out in swim lanes. So rather than just having one line or one flat list of all the things we want to get done, and then assuming that our velocity of points will get a certain amount of things done in a given period, you have to actually allocate them into the lanes where people who have that specialty will do that work. Like I have a front end swim lane, back end swim lane, you know, like a team one swim lane, a team two swim lane. And then you can actually plan over time. So you can like put things into those swim lane, you can put tasks into those swim lanes and know when the

overall thing is going to get done. But if you just assume a flat linear flow of tasks, then you can't take advantage of parallelism and you ignore specialization, which creates bad estimates. Well, let's talk about Scrum. You kind of compared it to Scrum a little bit. Yeah. Basically, Scrum is instead of saying we only do one thing at a time, you can have multiple works in progress at the same time, and you commit to delivering a set of tasks in a given period of time called a sprint and you kind of like grab a chunk of work and say we're going to work on we're going to do these things in the next week or two yeah exactly and you have a you have meetings sometimes called rituals where you actually do the planning for what is what work is going to

get done and you do estimation right where everyone says it's this many points to do that certain thing and then you put those things into a sprint and then you stop putting things in when the number of points exceeds your velocity which is a measure of how many points you think your team can deliver in a sprint. So yeah, I don't know. I've seen Kanban used effectively on teams that have hard to plan work, like infrastructure teams or site reliability engineering teams, teams where it's like things just come up and they have to deal with it in a timely manner and they can't wait till the next two weeks sprint. Yeah. It's interesting you mentioned the requirement to not add new stuff to the sprint because i feel like that is a feature of scrum

there's a lot of there's a lot of rules and it depends on who you talk to what they are and how how strict they are and but it feels much more prescriptive than kanban which maybe that's again just my lack of familiarity with kanban but it sounds like neither of these is what's happening it sounds like they're sort of just planning the next project and then they work on it. And then when it's done, they plan the next project, which is also, it doesn't have a catchy name with a bunch of salespeople, but it's certainly a way to deliver software, a secret third way. We'll call it Dave's way. Yes. The best way. It's amazing. Yes. Over here. You would not believe it. So although I believe it's a good thing, I've not actually worked this

way. Is it all it's cracked up to be? I have a bunch of thoughts here. One thought is if you haven't worked that way, you could pitch this as an experiment and hopefully you have some motivation for why you would like to try this out more than you've given here. You say you feel like we'd be more effective as a team, but you need to pitch it. If you're just pitching, hey, let's try it out for a couple of weeks. I think the bar for evidence and preparation and stuff is probably a little bit lower than if you're saying we should move to working this way. So I think if I were you i would try to test it out and i would also try we talked about this at the beginning but i would try and outline the outcomes that the business wants from whatever process you use

and show how the current process is delivering those and then have your hypothesis for how this this different process would help process change especially an established company always comes with some pain there's like an activation energy where it needs to be it needs to be like three times better to be worth the pain of like switching everything because some things are definitely going to be worse it's just the nature of it so i feel like if if you can test it out gather some some experiences and then put together a more detailed proposal for why you should work this way i feel like that'll give you the best chance of doing it. It will. But also, in my experience, if something isn't happening yet, and someone

shows up and says, I want to change the process, the easiest answer is no, because you don't have to do anything. But if instead, you just start doing the new process, and then when someone notices it, they can say, hey, what's this process? You can say, oh, this is how we work. It's been working great. Here's all the benefits that we can tangibly point to because we've actually been doing it. We're not hypothesizing about the future. We're actually recounting the past. We haven't had problems with X and Y and Z, and it's so much better. And then people are like, oh, okay. And now suddenly the default is yes, because now to change it would be to disrupt something that's already working. So as long as this process launches and doesn't cause any major

problems, you actually have pretty good legs to stand on to make a case that it's a good thing to keep. So it's a little nefarious, little under the table, you know, like, I don't know if that's the right metaphor, but kind of going around people's backs a little bit, I guess. But I don't know. It does work, I think. That's a good point. Spoken like a man who worked at a large company. Oh, I never violated the process of the large company. Yeah. I felt like there it was like a virtue of who could follow the process the best. Oh, interesting. It's like, we're really good at this scrum planning process that you've prescribed for us to do.

yeah driven from outside the technology team i'm still trying to understand what that what did you mean seven years ago driven from outside the technology team does that mean there's a a non-technical org that kind of owns this agile like do you have scrum masters or something i don't know i guess we will never know yeah but i i do think i'm gonna keep harping on this if you can deliver what the business needs right you can abstract over how you do it if they need estimates cool do whatever you want do kanban give us estimates update us when they change if they need coordination with other teams cool do that i'm sure you could do that with kanban so if you can provide like an interface and and hide the implementation then you get to do

whatever you want in your team as long as you produce great outputs. I think that's probably true. Businesses care a lot less about how you do your work than many people might realize. All they care about is results for the most part. Some businesses hyper obsess on exactly how you do the work and sometimes they have good reasons for that and sometimes they don't. But for the most part, in my experience, if you get great work done and the business goals are met, I don't really care how you did it. And often if there's a big initiative to have everybody work in a certain way, it's to solve a problem. And if you just do a really good job, then you can kind of hide it. If stuff goes wrong, then you will probably be examined closely, right? If the project fails,

it might not be because you're doing Kanban instead of this other process, but it sure will come up as a factor so yeah you got to risk it all to get the glory of a different process for organizing work the most boring thing in the universe but if it makes you happier i guess i don't know it's worth it have we answered this question i think so good luck good luck and yeah if you are still by some chance listening you recognize this question is yours from 2017 Please tell us what happened. Or maybe you're still stuck in this exact dilemma you've been waiting this whole time.

We freed you from your prison. What should people do if they want their own questions answered, Dave? Go to softskills.audio and click the ask a question button where you can fill out our form. Thank you so much to everyone who does that. We love getting your questions every week.

I read them to my children as bedtime stories. Dad, please. We want to hear about the pumpkin. no it's time to talk about agile-ish frameworks yes all right we will catch you next week