Product or Technology? Where Should You Focus Your Attention?

Transcript is auto-generated and may contain errors.

Hey folks, I'm headed to CrossFit here. It's uh Wednesday morning. Going to go to Reddit for a topic. Um and the TLDDR on this one, this is from experience devs, is someone's talking about being um product focused versus like I guess like more technology focused in engineering. So my understanding the the comparison they're trying to draw it looks like if you're looking at like technology strategy. So I'm assuming like the code base how that's evolving like different aspects of the product or service in terms of the code structure um looking at that kind of strategy and direction versus uh the product right and they're I think their side is that they're saying you know feel like maybe I'm going a little crazy here because I'm like very heavy focus on like the product side but it seems like um everyone else I'm working with is not.

And so I figured this would be an interesting one to talk through because um some some different perspectives. So friendly reminder, if you are interested in having your questions answered, this is the first time that I can actually say this, go to codemute.com and submit your questions. I finished the question submission thing. Uh otherwise, of course, leave below in the comments. I just wanted to make sure I had a website where you could submit them to. So, uh, go ahead and do that. You can always fall back to finding me on social media. It's just a dev leader on any channel you want. Send me a message. You can be kept anonymous if you message me or use the website. There's an option for it. So, happy to answer your software engineering and career development questions. So on this one, um I personally have kind of written both lines, but ultimately uh I I feel that I need to align more to like uh the product kind of kind of side of things.

And I say this not to uh not to suggest like it's binary like or you know can only be one or the other. So, it's not just product or just code and and tech to look at, but if I had to lean, uh, it would certainly be towards the product side. Um, the reason I say this is because I think probably because I spent like 8 years at a startup and I I want to say that I feel like the only reason we were successful is because we were doing that. Now, that's a a loaded thing to say. I realize I can't be the only the only thing that contributed to it. But I think that by leaning that direction and constantly like with a healthy tension of, you know, on the tech side, so like uh having discussions about tech debt and things like that.

I think constantly like putting in um or the majority of the time I should say putting in front like the product focus was the right decision. And I think this pisses a lot of people off or they don't like it especially as software developers because a lot of us are very focused the other way. But I think that I would probably you know be more aligned with the original poster of this Reddit thread. Um, the thing that I don't think a lot of people realize, like when you say it on the surface, it's probably obvious and people are like, "Sure, that makes sense." But, um, I feel like until you live it, you don't um, you don't appreciate it. But like, customers don't pay for clean code. I've literally made a whole video on this, right? It doesn't mean that you shouldn't try to write good code or anything like that, but that's literally what customers have no visibility into.

They feel the side effects of a crappy codebase. But if you could literally snap your fingers, right? You say you have this big legacy code base that's 10 years old. If you could snap your fingers and make it whatever the definition of perfect is, if you could do that, it's not like the next day you could charge more money to your customers. And that's because they simply don't know or quite honestly give a what your code looks like. They care about the side effect of those things, right? They don't observe what the code looks like. So in terms of like technology direction, code direction, all these types of things like they are important. Please do not misunderstand what I'm saying. They are important, but especially from being at a startup, there's always going to be this opportunity where like you could be thinking about features, enhancements.

You could be think prioritizing fixes, behavioral changes in the workflows um to be able to either keep customers or acquire new ones. And when you are going from nothing to something, that is all that matters. It's all that matters. If that means you have to acrue some tech debt, that's fine. You know, you're going to have a paying customer that's going to at least help pay the team. But people when they don't live through this kind of thing, you kind of take for granted that like the money just comes in. So of course if the money's just coming in and we don't have to worry about anything, sure, focus on the technology side of things, right? Why not? Because when you do that from an engineering perspective, you can get ahead. It totally makes sense. But if you are not in that position, then you need to prioritize the product stuff because you need to get customers.

You need to keep them and you need to get new ones. So, this has always stayed with me. Now, if I shift gears a little bit here, I always think that's funny like on code commute, like is that an okay thing to say? Like shifting gears. I don't mean it from like the fact I'm driving a car just you know I always thought it was kind of funny though but um I work at Microsoft now I've worked on two platform teams in Office 365 over the past 5 years as platform teams especially focused on supporting like our internal partners I am I feel like especially in comparison to where I was extremely far removed from like the customer and in this case the customer can be truly end users like people outside of Microsoft or could be our partner teams within uh Office 365 that have services that they're running for Office 365.

So just given the nature of being on a platform a lot of the time it seems like we're not building like a a feature that someone's asking for and the platform's already established, right? That's the the big thing for me that's different in both of these cases compared to where I was. I was in at the beginning trying to make sure we could get users and keep users. In these two scenarios, I'm not. We we're guaranteed users. The users are literally the other people in our organization that we need to support with our platform. So it's interesting because for me like my dayto-day over the past 5 years the emphasis is quite the opposite of what it used to be. Doesn't mean that my beliefs have fundamentally changed but I spend a significant amount of time thinking the other way. Like we need to make sure that we have like a code base that is sustainable.

But we need to make sure we're cleaning up these other things. Um, in fact, the another big difference is that I just want to give you an example like because we're a platform and we have APIs for other people to call. There is literally like feature work that is the equivalent to refactoring APIs to simplify them like introducing you know uh a smaller uh API surface area for people to work with so that it's like a better experience because that is part of the product and the feature offering right I didn't live in a world like that before right the world I used to live in you could you But we could break all the APIs and stuff we want because we owned both sides of those. It would just be I don't know like how much pain we want to live through in certain areas versus how fast to move like whatever.

It's an internal decision here. It's not I mean it's internal at least to Microsoft but like not within the team. So, I've definitely had to to shift my mindset more to like focusing on more sustainability, that kind of thing. I'm coming into code bases that are that are legacy code. Um, you know, that have gone through like different elements of the systems have gone through rewrites and things like that. Um, and the team members like they've experienced like the growth of the system. So they're they're also like okay got to prioritize these things. But the it's just interesting like just to give you another example um I own part of our our tech stack that does caching um and it's you know helpful for making sure that we can route trillions of requests per day. So it's pretty significant. That's trillions with a T. Um, so a cash is really important in this scenario.

Now, one of the features of the cache is when I say a feature here, I don't just mean like a partner can go use this feature, but one of the features or capabilities is the fact that it should have low latency, right? There's an SLA around that that's very low because we need to have low latency. That's a feature of our cache. How do we get lower latency? Well, there's lots of things like cleaning up code, reducing allocations, examining hot paths and trying to make them less hot, right? There's things like this that are quite literally cleaning up code and refactoring code. So again, it kind of blurs the lines because um the way that we go introduce, you know, the fixes or improvements to the features in this area happens to be a lot of like code cleanup. It's a lot rarer that someone's like, I wish your cash could do this.

I'm not saying that doesn't happen, but that's a lot more rare compared to like how do we make sure that in these various scenarios of the cache being used that our latencies low. So again, I'm I'm trying to give you some different sides to this because I don't think that there's like a an absolute right or wrong answer. I just thought it would be an interesting one to walk through. But I I will always like I I would need to be convinced somehow that you know not thinking about the sort of the product side first like what are you trying to deliver to customers I would need to I don't know how I would be convinced otherwise that that's not more important because in my mind if that's not the thing you're prioritizing then what are you building software for in the first place? Right? Like if we're if you're at a business, maybe that's a key differentiator.

If you're at a business, business is in the in the business of making money, right? You have a business and you do something to deliver value so that customers provide money in return. And the side effect of that is that the employees can get paid and the business can grow. And I realize it sounds obvious, right? But that's fundamentally why I will always lean more towards product side. And I know that on the internet when people hear me saying that, they want to automatically jump to no, no, no, but you're wrong. That means you're just going to accept tech debt for forever and it's going to, you know, you're going to hit a wall. And it's like, that's not what I'm saying. Um, I am saying that I would strategically take on more tech debt if it meant that we could do better user acquisition or retain users or whatever.

I would depending on the scenario, right? every like we're not analyzing anything right now to go weigh the pros and cons, but more than likely I would or it would be a conversation of like do we need to delay this a little bit so that the impact of the tech that we're going to introduce isn't so bad or could we come up with a strategy where like we don't have to stop delivering but we can like do a slower roll or something. There's a million ways to go slice and dice this, but like for me the product focus is going to take a priority. It needs to. I think what gets missed is that like in that sort of debate about you know product or tech is that um if the if the prioritization around technology changes and codebased direction and stuff if that's not

facilitating the other end of it then what are we talking about right this is I have always encouraged people especially coming from a startup being an engineering manager and an individual contributor at the same time for 8 years when engineers are like we don't get to work on tech debt it's not fair um you know we code it this way and like we're never going to have a chance that's why we want to take longer upfront what gets missed is that people in this case engineers uh generally have a difficult time of trying to convey business value for for addressing tech debt or for why changes like we need to go spend more time in this area of the code to clean it up or do whatever. You need to be able to convey the business value of that. You're trading time. Time costs money. So what's the business value of it?

It it is an investment. And I feel like living and breathing in a startup for eight years like really was eye opening for that because it's like we got a million things we got to do and you have to ruthlessly prioritize. So that would mean like if someone could say, "Hey, we got to go clean this up because I know based on our conversations, uh, you know, as the product owner, you're trying to deliver more in this area and we have to go touch this a lot coming up or you know, for the last 6 months, like we've been basically moving super slow because this area is constantly on fire. like we need to go address this so that that we can get our time back because here's how much time we're spending here. Um or we're about to go spend this much time here uh to go build new features and we've already seen how brittle it is like we need to go pay down this tech.

You need to start having conversations that way, right? when you're talking about architecture because this is tactile aside. You want to talk about architecture and future direction of the codebase like it it shouldn't just be because it makes the code more clean because that's not a business value, right? You could say something like we need the architecture to shift in this direction or whatever. It happens to make the code more clean and like here are the side effects that impact the business. the cleaner code. If you could somehow demonstrate that when this is cleaned up in a certain way that that's going to reduce the amount of development time or engineering effort, that is important. That is going to be something that people on the business side of things can understand. So when you are when you're frustrated about like technology choices not being prioritized or we're not putting enough effort or thought into it, um shift the conversation.

You need to be able to communicate to the other stakeholders in a way that's effective for them to understand if they're the decision makers. But ultimately, like I said, I will gravitate more towards the product side. Because I think without that, you don't have a business. If you just like writing code, that's totally cool. Totally cool. But from a business perspective, I'm not sure that's the the strategy. And there we have it. I'm at CrossFit. Would love to hear your take because if you want to disagree with me, that's totally cool. But that's my perspective on it. I will see you next time. Take care.