4 ms·

One tactic I have used with moderate success is to explicitly carve out time for fixing tech debt. A few things we’ve tried: 1. Pledge to schedule 20% (pick yo

One tactic I have used with moderate success is to explicitly carve out time for fixing tech debt. A few things we’ve tried: 1. Pledge to schedule 20% (pick your percentage) of the sprint as tech debt payback rather than stories. The problem here is that this stuff tends to drift to the bottom of the sprint and then slip if anything else is delayed. This is where most teams start as you can start at an arbitrarily small percentage and scale up gradually. 2. Fixit Friday; the middle Friday of a sprint is for fixing tech debt, not working on sprint tasks. Engineers are encouraged to advocate for tasks they think would speed us up, and we also have done themed pushes where e.g. the whole team chips in to migrate the codebase to a new linter. One issue here is that it’s hard to make progress on larger initiatives, which leads to: 3. Fixit Sprint. At the beginning of the quarter there is often a bit of downtime as the leadership digests the last quarter and plans the new one. This can be a good time to take a sprint off product work, and really dig into some substantial re-tooling or refactoring. Depending on how much resource you’re allocating to tech debt, you can mix and match these, I’d say 1 & 2 are probably mutually exclusive, but you could combine either with 3, or just do 3 instead. I think it’s important to be clear about when you are taking on tech debt, and when you have cleared the hurdle and are paying it back, and clear rules like these help to communicate that message.

valenterry 6y ago
I feel when you have to do this, it's already a lost cause. The company either thinks strategically or it doesn't. If it doesn't then it will only hurt you if you do. Just deal with it, work in the way they except (i.e. create even more tech debt for some fast results) and once it all crashes, tell them the whole thing needs a full rewrite (which you know will fail anyways). Not really much you can do here except for leaving. If the company thinks strategically, then no need for something like a 20% schedule. You should be empowered to make these decisions yourself and you should sometimes create a lot of strategical tech debt and sometimes take a month to fix something if you know it will pay off. You are the expert - you need to understand the business for these decisions and then you communicate back (as you already mentioned), but that's about it.
- JamesBarney 6y ago
  > You should be empowered to make these decisions yourself Very few tech leads or devs are empowered enough to tell upper management they aren't going to work on the tasks assigned to them and will instead work on fixing a technical debt issue. And I can relate to this, because if I asked a dev on my team to work on building out a new report a user asked for and they respond they're going to fix technical debt instead, I wouldn't be happy. Also we already know how this ad hoc approach to technical debt works in most organizations. You get 0% to work on technical debt.
  - valenterry 6y ago
    > Very few tech leads or devs are empowered enough to tell upper management they aren't going to work on the tasks assigned to them and will instead work on fixing a technical debt issue But everyone is already doing that _to some degree_. Everytime you do a mini refactoring, and be it just some code formatting, isn't strictly "working on the tasks assigned". Unless you define "working on the tasks assigned" a bit wider, which you should. > And I can relate to this, because if I asked a dev on my team to work on building out a new report a user asked for and they respond they're going to fix technical debt instead, I wouldn't be happy. But you, as the lead developer (or however you call it), should have some insight on the longer roadmap. And if you see that there will be a lot of new reports necessary in the future and the current reporting-system has a lot of tech debt, you should decide if this tech debt should be tackled and then align with your team to do it. And this is what my point is: you should not even have to tell your manager (unless he is the one to decide if the tech debt is tackled or not). You should have all the necessary information and decision power regarding resources, priorities and technological&business strategy to make this decision. If you don't have that, your manager needs to have that _and_ needs to have the competence to make the decision about refactoring without having to rely on your or other technical people. If he can't do that (which I've seen is often the case) then this is where the problem lies: you are not empowered enough and you can't make the decision yourself, but you should be the one and not your manager. In the same sense, you should not be the one to decide how your developer implements the new report. Maybe he will decide to pull in a new library, maybe not. Maybe not doing it would create some new tech debt or the other way around. But that should be his concern, not yours. Your job is to tell him what the priorities are and that's about it. > Also we already know how this ad hoc approach to technical debt works in most organizations. You get 0% to work on technical debt. If the decision makers don't care and you can't educate them about that you should be empowered, then I believe there is no point in fighting. It will just make everyone unhappy. Leave or create a lot of technical debt while moving fast until the company is stuck. Who knows, maybe that's better? The market will make the decision.
deleted 6y ago
[deleted]

valenterry 6y ago

I feel when you have to do this, it's already a lost cause. The company either thinks strategically or it doesn't. If it doesn't then it will only hurt you if you do. Just deal with it, work in the way they except (i.e. create even more tech debt for some fast results) and once it all crashes, tell them the whole thing needs a full rewrite (which you know will fail anyways). Not really much you can do here except for leaving. If the company thinks strategically, then no need for something like a 20% schedule. You should be empowered to make these decisions yourself and you should sometimes create a lot of strategical tech debt and sometimes take a month to fix something if you know it will pay off. You are the expert - you need to understand the business for these decisions and then you communicate back (as you already mentioned), but that's about it.

JamesBarney 6y ago
> You should be empowered to make these decisions yourself Very few tech leads or devs are empowered enough to tell upper management they aren't going to work on the tasks assigned to them and will instead work on fixing a technical debt issue. And I can relate to this, because if I asked a dev on my team to work on building out a new report a user asked for and they respond they're going to fix technical debt instead, I wouldn't be happy. Also we already know how this ad hoc approach to technical debt works in most organizations. You get 0% to work on technical debt.
- valenterry 6y ago
  > Very few tech leads or devs are empowered enough to tell upper management they aren't going to work on the tasks assigned to them and will instead work on fixing a technical debt issue But everyone is already doing that _to some degree_. Everytime you do a mini refactoring, and be it just some code formatting, isn't strictly "working on the tasks assigned". Unless you define "working on the tasks assigned" a bit wider, which you should. > And I can relate to this, because if I asked a dev on my team to work on building out a new report a user asked for and they respond they're going to fix technical debt instead, I wouldn't be happy. But you, as the lead developer (or however you call it), should have some insight on the longer roadmap. And if you see that there will be a lot of new reports necessary in the future and the current reporting-system has a lot of tech debt, you should decide if this tech debt should be tackled and then align with your team to do it. And this is what my point is: you should not even have to tell your manager (unless he is the one to decide if the tech debt is tackled or not). You should have all the necessary information and decision power regarding resources, priorities and technological&business strategy to make this decision. If you don't have that, your manager needs to have that _and_ needs to have the competence to make the decision about refactoring without having to rely on your or other technical people. If he can't do that (which I've seen is often the case) then this is where the problem lies: you are not empowered enough and you can't make the decision yourself, but you should be the one and not your manager. In the same sense, you should not be the one to decide how your developer implements the new report. Maybe he will decide to pull in a new library, maybe not. Maybe not doing it would create some new tech debt or the other way around. But that should be his concern, not yours. Your job is to tell him what the priorities are and that's about it. > Also we already know how this ad hoc approach to technical debt works in most organizations. You get 0% to work on technical debt. If the decision makers don't care and you can't educate them about that you should be empowered, then I believe there is no point in fighting. It will just make everyone unhappy. Leave or create a lot of technical debt while moving fast until the company is stuck. Who knows, maybe that's better? The market will make the decision.

deleted 6y ago

[deleted]