|
This is kind of a weird one. Like, this isn't bad advice for advocating for yourself in general, and it's a far sight better than the approaches that I have seen at a lot of companies (i.e. "complain loudly enough until they give in" or "never, we just never address technical debt and we hope that doesn't come back to bite us"), but even still, I read this and I get the vibes of a dysfunctional organization hiding behind the scenes. Engineers shouldn't _have_ to try to beg, borrow, and steal time to work on technical debt. Moreover, "technical debt" in this article seems like it's being used more as a synonym for "crappy code" than the actual original debt metaphor -- there's no discussion of "interest" (i.e. accumulated costs over time), or payoff events (cases where the debt comes due all at once), or important business milestones (which can drastically affect whether you can even afford to pay attention to technical debt at this time), etc. Honestly, this shouldn't be something that non-leadership engineers should be concerned with at all. They should be working with engineering leadership to ensure that technical debt is identified and classified, so that engineering leadership can work with product leadership to prioritize the payback of technical debt at an appropriate time, in the appropriate order. Trying to solve this problem at the level of individual teams and individual PMs means that the larger scope of the business's needs aren't available to be considered. Is there a funding round coming up? A big partnership announcement? A hiring round? A hiring freeze? You don't know, and you won't necessarily be told, even if you ask. On top of that, the standard of measurement for improvement is flawed. The article is suggesting that "technical debt" as a whole is doubling the amount of time it takes to do features, but that's just not the way it works. Technical debt isn't just "crappiness of your codebase" -- you'll never solve that, no codebase is perfect. Technical debt should be tracked as individual, specific issues that will have specific negative effects (the database doesn't have appropriate indices and will get slower over time causing increasing performance issues, the version of the third-party API we're using is being deprecated and if we don't upgrade, we'll have a production outage, our User class has grown out of control and any feature that touches it effectively touches most of the app, causing bugs to appear at a much higher rate and slowing releases of these features, etc). I'm summarizing because this is already a long comment, but these issues should be even more specific than that: you need to describe the issue, the cost to fix it, the pain it's causing now, the pain it will cause over time and what that time frame is, and if there's any events that will require you to have the debt solved Or Else. Talking about technical debt with this information available gives concrete information about why it's valuable to solve. Talking about it with "we will move 2x faster" is unlikely to convince anyone, because software development isn't that reductive. You cannot guarantee that flat, project-wide improvement, and people will remember the time they spent three months not building features for no benefit they can understand. I feel like the approach specified in the article will work -- at best -- once. A lone engineer doesn't have access to sufficient information to truly make a case for why this is a good time for the repayment of a particular piece of technical debt, can't see the full spread of potential technical debt that _could_ be solved and should be considered, can't adequately convince people as to the benefits of having resolved the technical debt, and honestly shouldn't be spending their limited political capital trying to get their personal pet peeve fixed. If technical debt isn't getting fixed appropriately, that's an engineering leadership issue, and you should be working with engineering leadership to try to help them understand any debt they're not aware of so it can get prioritized appropriately, and then afterwards, work with them to make sure that the specific, visible improvements and "catastrophes avoided" are recognized and respected. |