1. Separate backlogs for product and tech
When product work and tech work live in separate backlogs, Product stops interfering in tech decisions and Engineering stops engaging with product priorities. It sounds like peace — it's actually a slow failure.
Product and technology are not separate things. Bug fixes, library updates, automation improvements, security patches — almost all of these have business value (reliability, security, speed of delivery).
The fix: every item on the technical list should have a clearly defined business value. Once it does, move it to the product backlog — where it gets prioritized alongside everything else. Reserve the separate tech track only for critical work too hard to explain to non-technical stakeholders.
2. The company doesn't understand the value of your work
If the business doesn't care about or understand your technical initiatives, those initiatives will always be the first thing deprioritized when "urgent" things appear. And you'll have a much harder time negotiating for hiring, training, or additional time.
The fix: make technical work visible. Hold monthly reviews where engineering teams present the progress of technical initiatives not tied to specific product teams. Show why the work matters in business terms — not just "we migrated to Swift" but "this reduces compilation time, improves developer experience, and helps with hiring because fewer engineers want to touch Objective-C."
3. Diluted focus
Getting 20% doesn't solve everything. If you assign a separate tech initiative to every single person on the team, each going in a different direction — you'll make no real progress anywhere.
The fix: focus your 20% on a coherent set of initiatives that contribute to a longer-term engineering strategy. Know your goals, know which initiatives contribute to them, and resist the temptation to address every technical itch simultaneously.
4. "We'll fix it later"
Once a team has 20% protected time, it becomes tempting to push things faster, assuming tech debt will get cleaned up later. It almost never does — the next sprint always has something more urgent.
20% time is to make things better, not just less bad. Even when building an MVP, it must be functional, usable, and reliable. Writing tests "after we push to customers" is a classic — those tasks almost never get done because you're either fixing production issues or jumping into the next initiative.
5. Ineffectiveness on large initiatives
20% is one day a week, 1.5 hours a day, or ~4–5 days a month. For genuinely large initiatives — breaking down a monolith, re-platforming — this means a year of context-switching to make 2–3 months of progress. It doesn't work.
The fix: large strategic initiatives shouldn't live in the 20% — they should become product priorities with business justification, full organizational support, and tracked progress. Save the 20% for genuine maintenance and smaller tactical improvements.
1. 产品与技术待办事项分离
当产品工作和技术工作分属不同待办事项列表时，产品团队不再干预技术决策，工程团队也不再关注产品优先级。看似相安无事，实则是缓慢的失败。
产品与技术并非独立存在。 bug修复、库更新、自动化改进、安全补丁——几乎所有这些工作都具备业务价值（可靠性、安全性、交付速度）。
解决方案：技术列表中的每一项都应明确其业务价值。一旦确定，将其移至产品待办事项列表——与其他所有工作一同参与优先级排序。仅将难以向非技术利益相关者解释的关键工作保留在单独的技术追踪列表中。
2. 公司不理解技术工作的价值
如果业务方不关心或不理解技术举措，这些举措在出现“紧急”事项时总会最先被降优先级。同时，你在争取招聘、培训或额外时间时也会困难重重。
解决方案：让技术工作可视化。每月开展评审会，由工程团队展示未绑定特定产品团队的技术举措进展。用业务术语说明工作的重要性——不是“我们迁移到了Swift”，而是“这缩短了编译时间，提升了开发者体验，有助于招聘，因为很少有工程师愿意接触Objective-C”。
3. 注意力分散
获得20%的时间并不能解决所有问题。如果给团队中的每个人分配不同的技术举措，各自为政——最终将无法取得实质性进展。
解决方案：将20%的时间集中投入到一组符合长期工程战略的举措上。明确目标，了解哪些举措有助于实现目标，同时抵制同时解决所有技术问题的诱惑。
4. “以后再修复”
一旦团队拥有20%的专属时间，就会倾向于加快推进工作，认为技术债务以后再清理即可。但实际上几乎从未实现——下一个Sprint总会有更紧急的事项。
20%的时间是为了让事情变得更好，而不仅仅是减少问题。即使构建MVP，也必须保证功能可用、易用且可靠。“推送到客户后再写测试”是典型误区——这些任务几乎永远不会完成，因为你要么在修复生产问题，要么在投入下一个举措。
5. 大型举措效率低下
20%的时间相当于每周1天、每天1.5小时，或每月约4-5天。对于真正的大型举措——拆分单体应用、重新平台化——这意味着需要一年的上下文切换才能完成2-3个月的进度。这种方式行不通。
解决方案：大型战略举措不应纳入20%的时间范畴——它们应成为具备业务合理性、获得全组织支持且进度可追踪的产品优先级事项。将20%的时间用于真正的维护和小型战术改进。