These are just examples, and one can always nitpick, but I hope some people get something out of this.<p>If you are a competent team lead and are a technical person who understands the substance, you understand relatively well what "glue" is needed and is valuable for your team and the company. Then when some engineer does that glue work, you reward them! You might have the glue items as part of the normal work item management, or then not, it depends.<p>When you have retrospectives, you can always review "our builds were failing 50% of the time in January but now in May, it's only 10%, big thanks to X for fixing A!". Or it can come up in personal reviews etc.<p>You don't forward everything to your boss or product manager to decide. They don't review your team's code either. But you of course have to communicate that you will have less capacity for a while to do features, since you're working on an internal thing. Then after that the team will have more capacity for features than before.<p>This is the kind of work the team lead is expected to do, to keep the machine working. They are not doing a good job if they only follow orders and the machine stops because somebody didn't specifically tell them to oil it. Or if the machine is destroyed because periodic maintenance was not performed.<p>It's of course bad if the team ends up spending most of their time building fancy internal things that don't produce value. It is tempting to end up building cool stuff. That is then the team lead's responsibility to steer away from. It's a balance.