Episode 433: My teammate pretends we decided, but we didn't and my team is getting worse and worse
31:29 Share

IT takes more than splitting a waterfall into sprint to be a great engineer of this is so skills engineering. Episodes thirty three, I am your host dave smith.

I am your host Jason dance. Soft skills .

engineering is a weekly advice podcast for software. Are developers who just can't quite reconcile that all these sprints look a lot like waterfall.

trying to imagine the metaphor of splitting like physically splitting a waterfall into a bunch of tiny little segments of falling water. Yeah.

it's like you just put a ruler next to a waterfall so you can say the first inch of the waterfall is sprint. Number one.

yes. Yeah.

we are going down this.

I mean, this is a common complaint and failure mode here described. But also, I don't know, I guess this is the hard part about trying to be Angel is is you have to, if you have a big thing, you to split that up into a bunch of small things that you can ship incrementally. You and I think sometimes you just can't do that .

yeah eventually you have to build something .

yeah I think i'm a waterfall apologist. Um I did have a coworker, one of the smartest st people i've ever worked with, who said the best project that they ever worked on was one hundred percent waterfall. And I was just the team was really good. They just did IT. So we should all switch to waterfall.

What I have learned of twenty years of doing a mix of Angel and waterfall is that the talent and skill of your team matters a lot more than the process you choose. Yeah, I don't know. We're talking about this.

I don't know. I the .

intro, we're both complicated. I made IT serious. Okay, right? Do you want to think your bitrate?

I do. yeah. Thank you to the people who are shouting. No, no. But that's not that who we are shouting.

Thank you. Thank you for all the shouting as well.

It's such a pretty ous level ah thank you to nick mou curtis upshall pool to to with little music ao gies so maybe that's like a song I don't know attributor none type object has no attribute to string have you are going to tell us to e ted timbre become a senior engineer insulted french fires are morally objectionable then from drone to play chase w Martin love up your type script with type od deb ney is not just to create on mars forming O O ogi I like chicken.

I like liverymen s mics please deliver trash panna cobos kenser dods neva is not just a plan in th of vocable system. Jie kim, all in upper case. Oh r this toxic pairt helicon A I best observably tool for A I red panda is best panda type script is a microsoft conspiracy.

Y JoNathan king, I beautiful functionally user documentation hi mom, i'm on a podcast. Ize, the creator of William Angel, that Kevin is a cool dude. Travis bread entails john grant, if you would like, in the selectors crew, go to Oscars.

The audio picked the supporters patron button and is a special shadow to code sale, who is generously given a large sum in order to support the good work we do. Thank you. go.

And then they cut off. Thank you. We appreciate you. And, uh, just makes my life Better to see how you tweet this every week.

If you want to join them, you can go to some school that audio click supporters on patron do the thing, and we will do the thing as well. We will both do the thing, and you'll be Better. Yes, you also get invite to our selection.

Am, right? Community group, what do they call IT now? Is IT still at org?

I just want you to know you've been using the term team and I haven't corrected you, but they haven't used that term. And like five years.

okay. Well, I call my kids the wrong name all the time. The show. I feel about slack like I do about my children. I can't remember the right name.

There was an awesome in the slack, in the slack workspace, which I think is what they call them.

Now there was an awesome workspaces. What this says, the you, yes.

there was an awesome tecum post about the slack logo that has required my brain for the Better and the worse at the same time. So if you want to go see that, mean you gotta go and contribute on patron and will send you just like and White.

And you can go look at IT. Just scroll down and check this channel a while.

Pretty good ah man.

this honestly the tecumthe channel in the soft skills enduring podcast slide workspace is IT is a daily joy for me and that I cannot say that about a lot of things but this one is so thank you to everyone who post in there. I just literally, i'm just a looker. I just consume the great means and they are so funny.

Okay, anyway, let's move on from this segment. Yeah, yeah. You want to read our first question? Yes, I do.

This comes from a listener name, Jordan, who says, hey, guys, I recently moved on to a new team, and my teammate has an interesting way of resolving differences of opinion. He simply says, we decided and then follows that up with his preferred approach. These are decisions that I know have not been made, this engineer's midd level.

So IT isn't the royal wee of a tech lead. How do I handle this? Something tells me that responding with, uh, isn't the right start. The right side is beautiful, is so good. We decided, we .

decided, why have I never thought of this? I know it's bRiley. Why bother convincing people when you can just say not that how IT is?

This is how tired I come to power.

This is I have worked in environments that felt like there was no room for changing anything. And the answer for for every suggestion was what we decided. And this is slightly different because because in that in those environments, that was more like we can, we can just change stuff like, why would we? Well, well, we we we decided a thing and thus we will never change IT.

But this feels a little bit different for that. Maybe there's some of that going on that it's like I don't know that the comforting stability of of doing the same thing that you have decided to do already that you buy up. Maybe it's not that.

We decided, yes, we did. Thank you so much for saving us all from endless discussion and chAllenging personal interactions. I, for one, welcome our new decision making. Overlord.

yeah, don't worry. I saved us all the work of trying to figure out what the team wants. I actually figured, get out by reading everyones mind. And so technique, like we did decide, I simulated in my head based on my perfect knowledge of what they all think and believe, why a decision we would have come to. And IT is this is perfect.

safest time. I'm efficient, i'm decisive and that's what we decided. How do you respond to someone who does this? I actually .

think the response could be the same, whether you think it's just them making up that IT was a decision or IT actually is a decision that you think should change, which is like we are free to change past decisions. And I think it's it's it's worth IT in this case. I understand we decided this, but I think we .

will be Better. I understand we all collect, including myself signed in blood, that we decided this. But i'd like .

the reasons at that. Yeah, maybe IT made sense in the past, but here's why I think it's the right thing to do right now. And if they can't point to anything besides, we decided, then you get to pull out. The old of foolish consistency is the hub garb of small minds, quote by raf emergent.

wow. Foolish consistency is the hub garabin of small minds.

Yeah.

what's a hob garland?

I think it's A D N D creature.

okay?

A foolish consistency is the hobgoblin of little minds. There we go. Hobgoblin is like, I don't know, it's like a little dem thing. I think I think the point means that IT is IT is A A negative trait that small minds fall into to just be consistent foolishly, purely for consistency sake because .

it's easier than actually confronting the chAllenges of yes, like the true, what's the word i'm looking for and like the deep analysis of why why I do yes.

And this quote was burned into my brain at one of my earlier tech jobs where we were very Young and we didn't really know what on about what we were doing. And we were all in, unlike the brand, is newest bleeding a stage tech, yes. And and we were like a clearer like, look, we found a person from two hundred years ago who said this thing clearly, we're good to use this niche database that why would we be? Uh, no, no, we're not small minded. Heck, no way.

we're not. We don't have any hob goblin ins.

No where hob goblin free eliminated them.

Therefore, we should definitely not do anything that we know works.

Yes, no, I I stand by my earlier statement though. I think I think you can you can say, cool, we decided good news. We can change our decisions and say that as dumas don't say as as rules as that, but like we decided, is not good enough if you feel like there is a strong case for changing things.

I like that. It's it's very gentle.

There is a cost. Yeah, I know what what would you do? Well, I mean.

there is one downside to the gentle approach here, which is that IT doesn't directly confront the fact that this person is, I don't know, the least heritable interpretation is manipulative, is like we didn't decide this. So do you think you would you find that would worth wild to confront that aspect of this problem?

I mean, you could you could say helping like where when did we decide IT point me to where we did IT because I I don't remember this decision. They are new on the team. So it's possible that either in reality, IT happened as a real decision before the this person joined or they can just say, well, was before you trying.

We talked about IT in the meeting. I don't know that if I mean, I think I would try this software approach first because IT feels I suspect IT will not make your working relationship Better. If you say, hey, I think you're lying about notice that you do this a lot. You say we decided when it's really just your opinion and I don't like that, I think you should stop.

You don't have to come right out and accuse them only of lying. You could give them the option to say you're either lying or manipulating us. Yeah does that helps off in .

little little? yeah. I mean, you could try and I don't know.

I don't think that's a thing the team decided. I think I think that's your opinion. Maybe confusing those two things that sounds little patronizing a little.

but I think one approach you could take here that is probably the one I would take is you could say, I don't remember deciding that can you catch me up to speed? Yeah that will make that will.

I am pretty sure when people talk like that though, when they say we decided and you're quite confident that the team didn't and and you're really confident that IT wasn't just you are on vacation one day and missed IT, then if you say that bringing out to speed, it's going to set them up to for an an awkward situation. Yeah and maybe that's okay. I mean.

they need to go through some awkwardness if they if they justify technical decisions by saying I don't know no, I don't want to with extra uh, december ling steps in between how do I handle something tells me the responding um isn't the right .

thread you could counter IT with. Oh no, we decided the other thing .

and I remember we decided my approach. Yeah, that's true. You could always talk to your manager about IT and say, I i've I have been in this situation a few times where they say we decided in, they say decision and I I don't know if that's a decision the team has made or not.

Can you help me understand maybe your manager won't have IT depends how close there to the technical going on of the team. So maybe they don't know, but you could at least get more information about, is this something the rest of your team is aware of and depending on how the conversation, maybe get advice from them about how to handle IT. Uh, the actual advice is probably less important than trying to make your man aware of the fact that you are dealing with this problem and so giving them context for any any outcomes that might result from this. If all the sudden youtube are fighting really, really intensely, I don't work together well or whatever, then there's there's some reason why beyond like all these new guys just really struggling on the team. Yeah, yeah.

I don't know. I I think we've given .

a range of good advice and I allow you I won't say which one you have to do. I will allow you the the option of picking your are .

saying we're presenting a menu, but that's not how I saw. We decided what to advise you.

Uh, okay, that's a good point. There are restaurants where the point of the restaurant as you go and they just give you food, they remove the decision from you. And so maybe this engineer, yeah like omaar says thing that I only know about because of rails never actually just a metaphor.

They use a lot about rails. But i've never seen or even heard of a restaurant and reality that does IT. I know that exists.

but but only because of the of your technical documentation reference. So good yeah .

there restaurants, where are they like mean to you and tell you know when you tell them what you want to order part of charm. So they're giving you A A the streamlining your experience right to removing all these things you have to think about you don't worry, you don't have to worry about what order. You don't have to worry about what to decide technically because it's ready decided.

It's ready been decided. Oh my god, say, yeah.

I don't know that how you say IT either.

but i'm sure that's perfectly mispronounce.

You know we decided that .

how you say we did are right.

Have we answered the question?

yes. Let's go on to our next one. Would you like to read this one?

I would. This is from an anonymous listener who says, i'm a principal engineer at a large tech company who's been with the same team for almost eight years now. The team needs to be part of a startup, and we've unfortunate enough to be acquired by big six, three years ago.

As a result, we've also more than doubled in team size. However, as we've aggressively grown over the last few years, I feel like we've inadvertently hired many average engineers. I find that some of our eurotech members simply pick off the ticket, the next ticket in the you, and do the bare minimum to progress the task.

What happens to the boy scope rule? My aside is I think that's like leave IT Better than you found IT basic. That's on right.

Yes, they are camps. I clean up reference.

yeah. Where do the culture of others ship go? This also affects the genuinely great engineers on the team who start feeling like the others aren't pulling their weight. Any advice on how to level up the culture? Or do I need to adjust my expectations and simply accept that any team of sufficient size will have folks from a range of abilities and attitudes?

A good question. yeah. So the team was acquired by big tech.

Yeah, I have. I have a metaphor swirl ling around in my head that I, in classic James and fashion, will not come out in any way that make sense. But i'm going .

to try and get IT out there.

Okay, so imagine you have a glass of some drink and a bathtub of some other drink. And the glass is like very concentrated and made in a particular way. And he dumped the glass in the bathtub like IT.

IT is, I think IT is easier to maintain and deliberately choose culture in a smaller organization because it's a lot more concentrated and you have a much stronger filter of do we hire someone at this company at all? And what does my point that doesn't make sense not? Do we hire someone of this company at all? It's like, do we do we increase the engineering team by ten percent with this one person? And then you dumped this glass into a bathtub and it's been deleted a lot by all the whatever is in the bathtub, which might be a delicious rupee you bring .

in there of the classic battle pair yeah that up.

peer. And and so your small team is is going to be much more impacted by the bathtub than the bathtub will be changed by that small drink you dumped in there like you're gonna move to the average team composition of this big org just because of the size difference, you you'll be deleted. And I think it's really hard to maintain very high quality engineers, add a very large company and then you have like there just personality differences. If he wants to work at the start up, people often are more interested in ownership, ownership and impact versus like i'll join the board at the big tech company in kinda ke, it's a well paying job. So I think there's lot of things that explain why this is happening.

I've seen an effect where when you hire someone on the team, they can either like, let's say, they are truly more talented than the existing team members, let's just say, like more talented on average, sorry, than the average of the rest of the team. I have seen that happen where the rest of the team levels up to meet them. But i've also seen IT where that person the new higher kind of levels down to meet the average. If you can kind of go either way, it's not it's not just like pouring a liquid into a bathtub where it's gonna low the laws of physics and have a uniform.

It's just no, i'm there's nothing wrong. So my metaphor, it's just like that yeah that makes sense. But I think but .

that's not what I described, is not quite exactly what the question ask her is describing the question ask saying what happens when you over time, you hire more and more people? Is IT just a given that you will definitely hire less motivated, less killed people because the team has grown to a certain size?

I don't think so. I actually think it's more likely that you will no one, no one who joins this team at a big mega corp. Will feel the same way as someone who joined IT as a start up.

I feel like that might be a bigger difference. Honestly, if you join a small start up, you're signing up for something that involves a lot of ownership. But I know i'm just repeating myself, but I don't know that is so much team size as it's like they're joining A A different company with different expectations.

And yeah, you you remember when I was a startup and you have a lot of holdovers from those days who bring a lot of the good qualities, but the people who would have joined this team as a small start up are not the same people who are joining IT. Now when it's embedded inside this company. Yes, true average engineers.

It's interesting because there are a lot of dimensions you can kind of rank or or describe quality of engineers. And this doesn't talk this doesn't specify as much that the technical skill it's IT is more about ownership. It's and maybe there is a technical skill thing on that they haven't said, but but I feel like it's easier to level up technical ability than IT is to make someone care. Yes, very much. yes. You know, I I .

disagree with the assertion, not your association, and I disagree with the assertion that IT is a that teams necessarily get worse as they grow. And I I, I, I certainly is certainly possible. And i've definitely seen organza to get slower, less ownership, less motivation and less talent as they've added more people. IT can happen. So don't get me wrong there, but I don't think it's a given.

I think that yeah, I do think IT takes a ton of effort and IT really is a hiring problem more so than anything else that you need to be very, very rigorous about who you let join the team to make sure that they're adding to the culture you want and not taken away from IT. And that means saying no to a lot of people, especially as you get bigger because what I what I believe happens is at a small startup, the small is of the company naturally only attract the kind of people that this question answer is talking about. People who are interested in taking on lots of otherness, people who are risk friendly, you know, like a small company could fail next week. Count me in. You know, like this is like a natural filter.

But also I kind of get to do whatever I want. Yeah, I get to say we decided and have that actually .

have that actually be true because I the only one of the team. yeah. So startups have a natural filter because there's a whole one of people who just wanted apply because they don't want any of that.

They they don't want to wear ten heads, they don't want the reps, they don't want the fast pace, they don't want the ownership. fine. great. So if you want to keep that filter for all the new people you hire after the company is bigger, well, you don't get to automatically to have the filter anymore.

Now you have to put in place a bunch of questions and interview process where you ask people, you know, like, hey, tell me about a time when you showed extreme ownership or tell me about a time when you had had to wear seven different hts, you know, all these things to trying to get to get a sense for the kind of people you hire. And IT is hard and you're going out to say no to a whole bunch of people who just never showed up when you were start up because they didn't apply yeah and I used the word to apply in two meanings. That was an excEllent double on toner that was well.

if you just start so inherently whitty.

that IT happens.

Yeah, I think there is a they specifically mention IT affects the genuinely great engineers on the team. And this sucks. I have seen this before IT.

IT is natural that after, I mean, people on Steve forever on a team, right? So if you've got a team of genuinely great engineers, some of them will leave like just after know through turnover nutrition over time, but feeling like the team used to be really high skilled and high quality and high ownership. And it's not any more.

I I could definitely see that driving away some of these people. And there's a vicious cycle there. Then you have even, even less ownership and even lower skill.

And so your principle engineer, so you have some kind of leadership. You're not a manager. You can just go fire these people. I think this is a thing I would be talking to the technical, like the managers who I don't know, probably a director.

Maybe if if I was like a company that got hired, acquired, I should say I would talk to them about this risk and say, hey, i'm i'm worried that we are going to lose these, I don't know, five really high quality people are because they're frustrated with these newer people that we hired. And there's a range of options around kind of raising expectations and training and moving these people out of the team into a different team, the big tech company firing them, whatever. But I think this is a hard problem to address just by yourself.

I feel like you would need to enlist the help of the the broader technical leadership on this team to do something about IT. Any advice on how to level up to culture? I mean, some of that you could you could do with feedback, right?

Like you see someone take a, take a to the very minimum. And say, hey, IT looks like you did the bare minimum. That's not good enough as a principal engineer, you you get to be a little more blunt to and hopefully you have you've earned the respect in the right to say we need to do Better. This needs to be Better.

yeah. And I think that's one of the one of the things that makes this answer, at least the advice that I would give more straightforward to execute on is that this person is a principal and engineer with eight years of experience on this team. So you can literally gather the whole team together in a meeting and say, I think we need a culture change.

I think we need to show more ownership, more pro activity and leave our code Better than we found that when we take on tickets. I don't I think we should avoid doing just the minimum. And you know, this is actually probably one of the most important things you can do as a principle engineer, and it's totally okay to say that.

And I I have been amazed at how when i've done things like this, where I stand up and say, I think we need a culture change and I think here's up, we need to do differently. I've been amazed at how willing people are to jump on board of that. It's actually really cool because I was worried people could be like, no, no, you're just complaining this there's always someone out there who would be like now dave, just he's just too picky or two demanded I not going to do that, not going to work.

But but the majority of people in my experiences, they they want to please you, especially when you're principle engineer. They yours of ten years, they know you're very influential and their job and success depends a lot on your opinion of their work. And so they're very eager to do IT.

And it's great. It's like, hey, you've spotted the problem is a problem that probably many people haven't spotted. Good for you. Now you have you have the authority to influence this culture. That's exactly what I would do is I would collect a bunch of examples for my own benefit, probably not to put him on on display for everyone else to see, but I would make sure i've got the details concretely understood in my own mind.

Then I would call a meeting and say, everyone, I think we need a culture change and explain exactly what the problem is and what you think we need to do to improve IT and then reinforce that a couple times with follow up emails or slick messages or give the program a name or something so that you can reference, sit on pr reviews and stuff and just say, OK, this doesn't really this doesn't seem to meet the standards of of project culture change. You know, what do you want to call IT? Yeah.

the java woche? Yeah, the java woke.

Y that's not a of .

possible sort that because snicker snack in that poem so you could, I mean, you could you could cobble that together. You're like slicing away the the complacency. If you can make IT into a military metaphor, big time companies love that crap.

So make IT about war somehow. And then it'll probably be more likely to get picked up. I like that.

Yeah I I would not do that without talking to a manager first. I wouldn't just drop a meeting on and say like surprise. I've decided this thing because you you want them to you don't want them to be surprised and ideal.

You want them to be behind IT and agreeing, and then they can help me enforce IT in IT. IT also says doing the very minimum in the boy Scott rule, IT could be code quality stuff. IT could be like product things, like maybe the requirements are fuzzy or not super fleshed out.

And so they literally just do exactly what he says in the ticket and don't step back and say what would make this work correctly. I i've seen that before, definitely. yeah. So make sure you're clear about what what Better looks like or you will maybe just get a bunch of like a bunch of extra linking rules like, uh, this is going the extra mile life left the code Better and that's not IT that maybe not what you want?

Yeah, maybe yes. Maybe not. Be specific about that.

right? What are some inspiring speeches in movies? I feel like the speech in independence day. Like watch, watch some stuff to get using. Yeah.

yes, we will not go quietly into the night.

Yeah yeah, the idea aor had some good ones. Yeah, I feel like they all again, they're also all very like war and battle related.

So if you can, if you can build a metaphor where you are somehow slaying something, then think both the speeches will be more applicable and it's more likely that a senior executive will say, I I like I like gump tion of that principle engineer yeah I I think it's cool that you are aware of this and and it's also really I like I don't know this is a nice story. It's called that you've been working on this team forever. They got a quiet three years ago.

That's that's a pretty long time to stay after an acquisition. So that seems like you have something here that you are willing to to work to preserve. And I feel like you could do IT.

I agree. And I think not only could you, but IT IT is and combat upon you. This is one of the duties of a principal engineers to maintain the culture of engineering excEllence in your organization.

This is not something that you can delegate fully to anyone else. It's not something that I would expect a people manager to do. It's your job. So i'm glad you asking the question, and I think you definitely need to do IT. And and I hope you know that this answer fills you with confidence that you can do IT and that you will be successful even though we probably can't tell you the specifics of what works best for conveying culture changes in your own company.

But we could, but we won't because that would remove the learning opportunity.

Yes, I actually have the answer written down right here on a peace .

paper but i'm he showed me and I saw that was .

after we decided.

yeah yeah the other thing you could do is the complete opposite and totally divest yourself of all ownership by quitting. So so you know there's no wners ship. I'm gonna the least ownership possible and not work here and anymore, right? But IT sounds like you're pretty invested. And like you, I mean, you work with great engineers. They're genuinely great engineers on the team that that's a cool place to be.

This is awesome. Great opportunity is a cool learning experience, especially if IT goes very yeah.

yes, yes, yeah, yes. True there. Question .

answered.

Okay, you knew what I was. Gonna ask, yes. And you decided, I mean, we decided.

decided the question has been answered.

Yes, we did. I think you do question, sorry, sorry if you .

want your own questions, answer to go to the skills that audio click to ask a question. But which we've released the form to the we decided form and fill out as much as little information as you like. Thank you, everyone, to all of you who fill up that question for him every week.

We love IT. Our question backlog is my most Price possession. We appreciate .

everyone who does that. Thank you. We will catch you next week. We decided to catch you.

Yes, we decided to get you next week.