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.
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.
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.
I think by talking explicitly about tech debt you can get the non-technical stakeholders on board. (It helps I think of you were warning them about tech debt when you were taking it on, too, and not just starting to educate when it comes time to pay back.)
In my experience teams run better when everyone is somewhat aligned on how much tech debt to be taking on or paying back.
I am sure there are other ways to get alignment too; I’m interested to hear what other leads have implemented. I could believe for some team compositions the “let each engineer figure it out” approach would work well, but I think that is kind of like the Agile “self organizing team” — it’s rare that you get to work in a team where everyone is experienced enough for a free form approach to work, especially when you are growing fast.
Your CEO (or whatever stakeholder you mean) should not care about _how_ you work, they should trust you to do the right thing and enable you to do so. They should also give you feedback and correct your course, but only in terms of what you work on and with what priority. They should not care how you do it.
In the same way your lawyer does not tell you what kind of legal internal documentation they do and if they go to court X or Y to ask for something, you should not tell that to your stakeholders. You tell them only high level things that are relevant. Tech debt is not one of them, progress and estimated dates is one. And just like how the lawyer recommends you a certain path, you should recommend one to your stakeholder. E.g.: "Yes we can build this feature, but we could also build this other feature, which is almost as good and takes half the time. I suggest to do it this way".
> I think by talking explicitly about tech debt you can get the non-technical stakeholders on board. (It helps I think of you were warning them about tech debt when you were taking it on, too, and not just starting to educate when it comes time to pay back.)
Let's say you are in the position to do so and they trust you. Do you think it is productive to "warn" them? Let's be honest: even for developers it is very hard to understand the direct and indirect impacts of tech debt. And that is even though they can directly experience the effects. How difficult do you think is it for people for whom this is just an abstract term?
TLDR: I think it is easier for you to understand the business goals and make a technical decision than it is to make business people understand the technical constraints and educate them well enough to take the right decision.
I like your second sentence though! If explaining technical debt helps with the "us" culture, it should be done.
It's just that, from my experience, it usually does the opposite. And I mentioned the reasons: it is too difficult to explain and to understand, even for developers. Also, the most important aspects/impacts will almost never be measured - not talking about development speed here (which is already too difficult to measure), but motivation, attrition, broken window behavior and so on.
A better way to create an "us" culture as a developer is to make sure to be involved into product decisions from the very beginning, including contributing ideas. And being hold to the except same KPIs/OKRs as other departments. That also means, as a developer you need to have the discipline to heavily sacrifice code quality and create technical debt sometimes and you might have to push this against other developers. That is the price to pay.
I fundamentally agree with this approach and there are companies that do as well. What is the term that encapsulates this sort of culture? Is there one?
If there is one, is there a reliable / repeatable way to determine during the interview phases if the company you're interviewing with is this type of culture?
I would say this is one of the strengths of the culture at my company and we spend a lot of time trying to get that across to engineering candidates. I'd love to improve our messaging there if we can, though.
We talk about a culture of trust, that we hire good people and then trust them to do their jobs. We talk about avoiding hierarchy and beurocracy where it doesn't help us. We talk about engineers driving their own work forwards and we make it clear that we're looking for people who can do that.
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.