Prioritizing Tech Work vs. Product Work: The Incomplete Story

Problem

Tech teams often grumble about not doing enough tech work and having to do only feature work. Meanwhile, tech debt keeps piling up, the platform becomes unstable because of scalability issues, maintenance is hard and hugely time-consuming, and cycle time increases. Tech teams blame product teams for not prioritizing enough tech work to what they reply by complaining about not having enough time as the business wants to keep new features flowing. As a consequence, increased pressure makes tech people tend to less enjoy their work, and increasingly start to leave the org -- poor retention additionally adds to a bad atmosphere, and soon the whole organization is trapped in a vicious circle of dissatisfaction.

Actions taken

As a leader, identify and document tech work that needs to be done. Use any tool of your liking -- text document, Jira tickets, Trello cards, a spreadsheet, anything you are comfortable with.

Classify the work as planned or unplanned, following the Four Types of Work framework (https://www.visionate.co.nz/the-devops-four-work-types) from the Phoenix Project.

Align with your product team on criteria for prioritization; the RICE framework would be a useful tool to start with. (https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/)

Product usually will assign a monetary value to the investment of building a feature that might be hard to specify for tech work, but nevertheless you should elaborate on why you want to do it, what it brings to the table and how it helps to progress the state of the platform -- if it contributes to improving scalability, improving cycle time, improving system performance or UX, addressing architectural debt, etc. Don’t hesitate to ask your product person for help, after all, they are not only experts but partners in crime.

After everything is compiled and listed down, assign some very rough estimates, using T-Shirt sizing (S, M, L, XL; defining more specifically what this means). Put this together with your product backlog, after which you can have an objective and factual discussion on what should be prioritized, how, and when.

Lessons learned

• Product and tech are two sides of the same coin and are intrinsically entwined together. A Tech Lead or Engineering Manager needs to be tightly aligned with the product and not acting as their opposites. It is the same team and we happen to be in the same boat.
• Oftentimes, tech people complain that the product side of the business is reluctant to consider their proposals, but in all truth, product people have a unique set of competencies needed to build the whole story, unlike their technical counterparts. Also, with a solid story behind your initiatives, it will be hard for the business to dismiss them.
• At a minimum, you should provide enough context and get enough context about product priorities. By providing this context, everyone will become more aware of the challenges you’re up against and would be in a better position to help you.
• If you are not able to handle the tech-product tensions by yourself, don’t be afraid to escalate to your superiors and ask for help.