> Technical Debt: At scale, tech debt becomes exponentially more expensive. Budget 20-30% of engineering time for platform improvements.
Does anyone else struggle to meet this percentage of tech debt getting done in sprints? If I ever get close to those numbers, tech debt always seems first to go when the rubber hits the road and unplanned work enters the fray
I've found tech-debt to be a false dichotomy with product work. They're all decisions made in the context of the moment with accompanying weakness in understanding and time. Convincing business partners of the value in addressing tech-debt - let alone defining it - is rarely worth the herculean effort vs business outcomes. It always comes down to faith: trust us to get it right... this time; whatever "right" or even better is - if that's a more preferable word. It's no more possible for Product to get it right the first time than it is engineering. Embrace the journey and make the best decisions one can - though engineering leadership should be alert for obvious counter-productive calls - and focus on iteration speed, as that's the only quantifiable, accountable process that I've found to becoming more right.
Scaling a distributed product team presents unique challenges. Success hinges on a proactive mindset to design systems for future growth stages. Key transitions occur from 10 to 30 team members, necessitating clear squad structures and decision-making frameworks. Developing playbooks for practical processes ensures smoother scaling and enhanced organizational efficiency.
> Technical Debt: At scale, tech debt becomes exponentially more expensive. Budget 20-30% of engineering time for platform improvements.
Does anyone else struggle to meet this percentage of tech debt getting done in sprints? If I ever get close to those numbers, tech debt always seems first to go when the rubber hits the road and unplanned work enters the fray
I've found tech-debt to be a false dichotomy with product work. They're all decisions made in the context of the moment with accompanying weakness in understanding and time. Convincing business partners of the value in addressing tech-debt - let alone defining it - is rarely worth the herculean effort vs business outcomes. It always comes down to faith: trust us to get it right... this time; whatever "right" or even better is - if that's a more preferable word. It's no more possible for Product to get it right the first time than it is engineering. Embrace the journey and make the best decisions one can - though engineering leadership should be alert for obvious counter-productive calls - and focus on iteration speed, as that's the only quantifiable, accountable process that I've found to becoming more right.
Scaling a distributed product team presents unique challenges. Success hinges on a proactive mindset to design systems for future growth stages. Key transitions occur from 10 to 30 team members, necessitating clear squad structures and decision-making frameworks. Developing playbooks for practical processes ensures smoother scaling and enhanced organizational efficiency.