We NEED An Architect! Execs Just DON'T Get It!

Transcript is auto-generated and may contain errors.

Hey folks, we're going to go to Reddit for a topic today. Um, just taking a break because I think there's one more question or topic from the email that was sent in around software engineering management that I'll address. Um, I just I was checking out Reddit and one that I came across in experienced devs, it was like right near the top. Um, I wasn't thinking much about it, but I clicked in and started reading it and this person wrote this big post and I'm driving so I don't have it right up in front of me. So, this is my recollection of it, but it was kind of like, hey, like, you know, leadership at this startup I'm at. It's like they're just not seeing it. Like, we got this problem where like, you know, the development teams are like everything's people aren't on track. like we're wasting time with tech debt.

Like we desperately need to bring in like an architect to go do this. And then they're describing themselves as like the most senior person on the team with like a history of doing like architecture stuff. And the whole sort of vibe that I'm getting from how they're writing this is like, are you trying to ask them to hire in an architect or are you trying to get them to say like you need to be the architect like to give you a title for it or something? Like it's it's kind of weird, but the um they're calling out all of these things like inefficiencies in the team, right? So, um, there's the team, it doesn't have that many. I think there's like seven people in the entire company or something like that. So, the team that they're on with the actual developers, I think, is like five people or something.

I don't know. Um, it's it's it's just the whole thing's small. And they're describing like, you know, one of the backend developers is like rewriting stuff and like not maintaining backwards compatibility. and he's complaining about this and some of the other developers kind of a similar thing going on and it's like okay so let's acknowledge that we got a couple challenges going on right there's some inefficiencies within the team but we're talking about a team that's like you know up to seven people at a company it's like up to seven people and uh this person's like very much concerned that leadership doesn't understand and they need to bring in an architect. You know, basically they're like someone needs to like sign off on the things that the team is doing. Um was how it was being phrased. And when I started to kind of get through this post, I was realizing like, man, like it is a tiny team, right?

I don't think it came across that way in the beginning. It sounded like they're at a company where this is like sort of this pervasive issue across all of the software engineering departments or something. I don't know, maybe that was my interpretation. But by the time I got to the end, I'm like, "Okay, we're talking about someone who is on on a team at a startup and they got people that have maybe what you might argue are like some focus issues on um what is the business priority to be chasing, right? So, for example, if you have people that are uh heavily refactoring things, like is that a good use of time? Uh even what this person's saying, like they're not maintaining backwards compatibility, do you need to like is that even does that even matter? I think most people would want that, but like for what you're building, does that actually matter?

There's it just seems like it's pretty typical stuff. And the solution that they're proposing to implement is we need one person that is the gatekeeper. That's kind of the take that I got from from their post and they're sort of frustrated that like it's not being acknowledged that this is like a necessary thing. And um it was kind of interesting. I scroll through some of the top comments um and there I think some other people had the same observation where they're like man like this the company is like one small team like you don't need to introduce like red tape to go solve this problem. Um, someone else made a comment that was along the lines of like what it sounds like is that you have some engineers on the team that like maybe aren't they weren't like trying to be condescending I don't think

but they were kind of like maybe they aren't the best or maybe they need some more guidance kind of thing and they're like and that actually includes you too like it kind of sounds like you're a little misdirected on this and I thought this was an interesting topic because it reminds reminds me of one of the last videos uh that the the person who wrote it asking about software engineering management and like staffing teams and stuff. This is coming from an individual contributor on the team versus the engineering manager on the team. And it's like you know we have we observe inefficiencies, we see challenges and the solution is to introduce a new role, introduce a person to go solve this and it's like I genuinely don't think that that's a good approach. I'm not saying it can't work. I'm not saying that either this person becoming an architect and having sort of uh you know that kind of sign off capability couldn't work.

I'm not saying that bringing in an external hire and giving them an architect uh title couldn't work. I just don't think that it's the best move and I don't think it's a great move even. Um, I think that instead of adding more, right, I think instead of adding more to solve this problem, I would say how do we try to work through this problem with what we have currently? Because I don't think that adding more people or adding a gatekeeper or, you know, bottleneck into the process is going to be the thing that gets you what you want. That's why I'm trying to say like I think it could work. I'm not trying to say that's not possible. I just don't think that it's the I don't think it's a way that I would ever recommend to people. Um cuz that's going to come with its own complications.

You're going to introduce a new person, right? Or even if you give this person the title of architect, like why do they need that title? I don't understand. And some of the comments I think were pretty spot on with this because again, maybe I didn't read the post carefully enough. I can't really tell if they're suggesting like I need to have this title or not because they talk about themselves in a way where like they should be capable of doing that. And someone had said like your company doesn't need to bring someone in. Like basically like why don't you just start doing these things? Like if you're observing these challenges, why don't you step up? What's going on on the highway here? Come on, buddy. Why are you stopping? Holy crap. What an absolute dummy. I haven't seen something so stupid since probably the last time I was driving.

Um, okay. Well, God. So, for context, the highway is completely backed up. This is probably the earliest I've ever seen this part of the highway backed up. I'm trying to get into the fast lane, but my lane is stopped. I look over and this guy is driving with his wife and staring back at me, going like my speed in the fast lane, so I can't merge in. And he's just like looking at me like, "Buddy, either speed up or get the hell out of the way." This is going to be a terrible drive, apparently. How long is this? So, my phone holder is broken. So, this is a 45minut drive. My god, it's just on Google Maps. It's solid red. Um, the express toll lane price is maxed out to be driving here and I am currently going 0 miles an hour. So, that's great. Um, I'm paying to be in a parking lot.

Anyway, back to this topic. So, I don't I don't really know if this person's after the title or not, but basically like if you're observing these things in the team, you should be trying to step up and be proactive and and try to address them, right? Um, I don't I don't see I don't see another way that's basically better than doing that. That's, you know, no extra cost to the company, right? They're not hiring someone. They're not introducing risk, right? I don't know if people realize this when they think about like small companies like that. If you have I'm just going to, you know, simplify this. you have 10 people at a company and you introduce one more person, right? Or maybe let's do like 9 to 10, I don't know, but basically it's around 10% around that when you bring in someone, your workforce is like 10% of that person represents it.

If they're not a good fit, that's automatically 10% of your your workforce. It's like not a good fit. So yeah, going from 9 to 10, one person when you have 10 people is 10%. So, it's very disruptive if you get a bad hire. So, there is a lot of risk when hiring. When you have a much larger company, sure, there can there's always going to be risk when hiring. That's why we want to do a thorough job, but um it can be really detrimental to get a bad hire at a at a small company. Um, the examples I was trying to give over the past few videos is like if you bring in someone like that, you bring in an architect, right? And automatically they're like they have the mindset like I'm here to fix things like I'm just going to change everything. That could be like pretty catastrophic.

It could work. I've never seen it work. I have never seen someone come into a team and try to change everything. And that's positive. It is in my experience, it has only ever been 100% negative. So I'm trying to acknowledge that there is in the realm of possibilities that it could be a positive thing. I've just never seen it happen. So it's not something that I would ever recommend to people. So yeah, you could hire in an architect. You could tell them you need to observe and then like slowly introduce changes or whatever and guidance. It's all possible. I just I think it's so much more work and effort and risk versus and sorry and even like time to uh I don't know time to impact. I guess it's it's like a negative on every single front versus someone who's already acknowledging these things enough that they're writing a Reddit post about it.

Like, dude, just start taking initiative. If you need support, then you should talk to your manager about trying to make sure that you're supported in these actions, right? Like, I don't understand. Like, I a title is not going to fix that. and then hiring in someone else. I don't I just don't understand why you need a whole other human being to go do that versus you already acknowledging these things and then trying to make the rest of the team better. So anyway, this video will probably be probably be pretty short. I just wanted to talk through this one because I thought it was a very interesting example where we see from the individual contributor perspective like let's add to the team to be able to address sort of like team dynamic challenges. Um not just an engineering manager being like I need more headcount, right? Sometimes I think people see the engineering manager going I need more headcount.

Um, and there's not I don't think it's like for every engineering manager, but I think that there's like this um this negative perspective sometimes where it's like, oh, engineering managers or and above or like they're just trying to grow their empire. They're just trying to have more people that report up to them so they seem more important. And like, yeah, I've seen that before. So, I'm not trying to say it doesn't exist, but um I liked this example because in my opinion, it was demonstrating the same kind of thing can happen as an individual contributor. So, if you find yourself in a situation like this, right, I would recommend that you try being proactive, right? You're identifying these challenges. You're seeing where the opportunities are. you know, you're going, "Hey, like these people are spending time um on the wrong things." Like I think someone on the Reddit thread was like, "You don't need an architect.

You just need like someone who's stepping up to be a team lead." And the interesting part about that is like that can be a very informal thing. Again, like you don't need a title to be taking the responsibilities of that on. you could be starting to live and breathe that as part of your role on the team and then as the company's growing it becomes a much more natural thing to be like you know depending on titles and and how all that works to be like well we don't have team leads or tech leads we should have that and like clearly Jimmy over here has been doing that like they're living and breathing that already so let's give them that title I would argue the same thing if they're if they're making a um a statement that they they think that they should be the architect or something cuz again I can't really tell from how they wrote it if that's what they're suggesting.

Like why don't you start demonstrating that? That's like most of the time we're not necessarily talking directly about a a promotion, right? It's like a title change. Technically, it would be a promotion, I guess. I don't know. But when we talk about promotions, it's extremely rare that you promote someone being like, I'm going to promote them and hope that they can do the job at that level. It's very rare. It's almost always the exact opposite way, which is this person is operating at the next level and they've been demonstrating that there's consistency there. Let's get them that next level. You know, one of the major reasons for that is like there's a lot of churn that would come if you were to promote someone to that next level and they were not ready or you took a risk in doing that and now you have to go, okay, you're at this new level, you got promoted, but like you're underperforming now.

So, what are you going to do about that? That's a way shittier position. So try to avoid that. So if you're in this position, I would say take initiative, bring visibility. Um I don't I don't like the idea of jumping to additional roles or additional headcount to be able to solve this problem. Personally, I think that what ends up happening is like if there's inefficiencies within the team already, okay, this is how the team has been operating sort of a combination of like team culture, the software development process, all these pieces coming together. If you try to add into that and like to try and fix it, like are you just basically putting a gatekeeper in that's going to be like no wrong thing to do like go do it this way, no wrong thing to do, go do it this way versus like why don't you look from within and get the team to rally around like change in a positive direction?

Because instead of having a gatekeeper, why don't you get like introduce fundamental change that comes from the team, talk with the people on the team like why are they spending time rewriting stuff, why are they doing breaking API changes? Start talking with people about what that means. work with people in uh you know product management, other stakeholders to have conversations about like you know next time we have a a situation like this should we be maintaining backwards compatibility? Do we actually not give a crap? I've had both situations in my career where we're like we're just going to say we're not maintaining backwards compatibility. That's it. And that's been to like with customerf facing features, but like more specifically like just internal stuff like especi when you're that small, it's like it's way different if you're breaking backwards compatibility and you have like multiple teams that are going to be impacted by that.

But if you're just talking about something where like you own both sides of it, you have a lot more flexibility. It might be like you have to figure that out at deployment time if you even have a deployed service. I don't even know what this person's building. Like maybe that's a thing. Maybe you don't even care and you have a deployment blip that's like 10 seconds while an instance that has the old legacy API is coming down and the new one's going up with the new client. You might say, "Sure." Like, "We just shaved off like two weeks of development time for a a blip that no customer is even going to notice because we're going to do it on a on a Saturday." Like, I don't know. Like, there's just a lot of stuff about this post rubbed me the wrong way. Um, because it seemed like more red tape.

So again, just I would remind people that if your solution to this kind of thing is like add more red tape. I would say I think you need to start having the team feel empowered. Uh having the team acknowledge these things. I would do like more retrospectives. I would bring these things up in conversations. Have hard conversations in the team. you know, doing a retrospective periodically like what if you're doing sprints or whatever it's every two weeks or whatever your interval is, being able to be like, "Hey, something I want to talk about is I don't think we should be doing this and then talk about it, right? you all work together instead of like, don't get me wrong, I appreciate when people post stuff on Reddit because then I have other content, but it's in my mind I'm like, why are you talking about this to strangers on Reddit versus your colleague?

Just go talk to them, right? Like I think when I see stuff like this, this might sound I don't I don't mean for it to be too harsh, but like someone else already said it in the comments, but it's kind of like you might be part of the problem, right? Like I don't know, like maybe they are having these conversations with people and trying to work through it. They're hitting sticking points, then like work with your manager to get them to help support you on it. But I assume that's not really happening. Maybe I shouldn't. And if so, it's not happening. Like start doing that. That's the lowest cost thing and probably has the best return because it's going to make the entire team better and work better together. So that is my rant for the morning. I'm going to wrap it up there so I don't keep repeating myself.

Thanks for watching. I will see you next time. And a friendly reminder that if you want questions answered, leave them below in the comments. Happy to answer them for you. And if you want to be kept anonymous, you can send a message into devleader on any social media platform. And the codeccommute.com website is live, but the question submission is not live yet. So keep your eyes peeled for that. I'll announce it in one of the videos when it's good to go. And I'll post on the uh the YouTube community post tab so you can see that. But I'll see you in the next one. Take care. Thanks for being here.