Technical debt (known as tech debt/code debt/design debt) describes a situation when code quality is sacrificed in exchange for a quicker delivery. The expectation is that there will be time to fix the code or release an update later.The tech debt metaphor was first coined in 1992 by Ward Cunningham, one of the authors of the Agile Manifesto.

Technical Debt: “Release Now, Fix Later”

There are three main types of tech debt, which you’ll likely encounter in your Product Management career.<ol><li>Deliberate tech debt.  Dag Liodden, CTO of Tapad stated in his talk for FirstMark, “We sometimes deliberately incur tech debt to reduce time to market.”</li><li>Accidental tech/design debt. Tech debt can be a by-product of evolving technology and changes in requirements.</li><li>Bit rot tech debt. A component or system may slowly devolve into unnecessary complexity because of many incremental changes.</li></ol>

Different Types of Technical Debt

It doesn't do you or your team any good to feel like the team has failed because you've got a backlog of tech debt.Tech debt is a normal part of building products. The key to properly managing tech debt is to ensure you're keeping a proper eye on it by setting soft deadlines on what needs to be caught up on and when. Keep communication open and useful.

Technical Debt for Product Managers

<img alt="Carlos G de Villaumbrosia" src="https://miro.medium.com/max/500/1*ZIKfIeS-bSJ0I6G4QNKbCw@2x" width="48" height="48">When you’re just getting started in Product Management, there’s a mind-boggling amount of new terms and and theories to come to grips with, especially if you’ve never worked in the tech industry before.If you’ve come from an engineering background you’re already very familiar with today’s topic: technical debt. But if you’ve come from marketing or any of the other myriad background Product Managers typically come from, you might be scratching your head.That’s what we’re here for! To break it down and make it easy, and today we’re lifting the lid on technical debt.<figure><img alt="" src="https://miro.medium.com/max/500/0*h42YXKhmO8uUXP3-.gif" width="480" height="270"></figure><h1 data-selectable-paragraph="">The Basics: What Does ‘Technical Debt’ Mean?</h1>Technical debt (known colloquially as tech debt, code debt, or design debt) describes a situation when code quality is sacrificed in exchange for a speedier delivery. Development teams will take steps to push out a new feature, because it’s more important to deliver it quickly than perfectly. The expectation is that there will be time to fix the code or release an update later.The tech debt metaphor is essentially shorthand for “release now, fix later.”To the uninitiated, this looks like a terrible idea. Why on Earth would you ever want to compromise software quality for a speedier release?! Doesn’t that sound like a recipe for disaster? But it’s actually a strategic decisions, made when time is of the essence. It doesn’t mean ‘always ship bad code in the interest of speed.’The debt metaphor was first coined by Ward Cunningham, <a href="https://productschool.com/blog/product-management-2/skills/agile/agile-development-everyone-talking/?utm_source=medium&amp;utm_medium=medium&amp;utm_campaign=WeeklyArticles" rel="noopener ugc nofollow" dir="ltr">one of the authors of the Agile Manifesto</a>. In 1992 Ward said;<BLOCKQUOTE>“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.”</BLOCKQUOTE>He later went on to say;<BLOCKQUOTE>“When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs Technical Debt. This debt decreases productivity. This loss of productivity is the interest of the Technical Debt.”</BLOCKQUOTE>Ward has explained his debt metaphor in a few different ways over the years,<a href="https://www.agilealliance.org/introduction-to-the-technical-debt-concept/" rel="noopener ugc nofollow" dir="ltr"> the best of which you can see right here.</a>Technical debt doesn’t just refer to deliberate tech debt, but also to accidental and bit rot tech debt, which we’ll go into in more detail. These types of debt aren’t planned, but they are often part and parcel of product development, and something which Product Managers need to take into account.<h1 data-selectable-paragraph="">Different Types of Technical Debt</h1>There are three main types of tech debt, which you’ll likely encounter in your Product Management career.<h1 data-selectable-paragraph="">Deliberate tech debt</h1>Dag Liodden, CTO of of Tapad, described deliberate tech debt perfectly in his talk for <a href="https://firstmarkcap.com/" rel="noopener ugc nofollow" dir="ltr">FirstMark</a>. He says that engineers know the right way to do things, and the quick way to do things. “ We sometimes deliberately incur tech debt to reduce time to market.”<h1 data-selectable-paragraph="">Accidental tech/design debt</h1>Tech debt isn’t always a deliberate decision. It can be a by-product of evolving technology and changes in requirements.Business goals may shift, a competitor may innovate in the same space as you, or new data may challenge your assumptions. There are a number of scenarios which could render a feature you’ve been working on redundant.Accidental tech debt often occurs from situations that are out of your control. What matters more is how you respond to them.<figure><img alt="" src="https://miro.medium.com/max/500/0*WkTRTqitcYTvl_LZ.gif" width="480" height="480"></figure><h1 data-selectable-paragraph="">Bit rot tech debt</h1>Bit rot tech debt is the one you should try to avoid the most. <a href="https://www.wired.com/beyond-the-beyond/2018/02/bit-rot-tech-debt/" rel="noopener ugc nofollow" dir="ltr">According to Wired</a> it involves, “a component or system slowly devolves into unnecessary complexity through lots of incremental changes, often exacerbated when worked upon by several people who might not fully understand the original design.”This is what happens when you have ‘too many cooks in the kitchen.’ When individual developers work on the product without coming together to look at the big picture, sometimes the individual contributions don’t quite fit together.<h1 data-selectable-paragraph="">Technical Debt for Product Managers</h1>Managing technical debt is a key part of a Product Manager’s job, and there are a few things that great PMs do to properly manage tech debt, no matter which of the above categories it fits in to.Realize that it’s normal. Sometimes it feels like it’s following you around like a bad smell. The key is not to run from it, but to realize that it’s all just part of building products!It doesn’t do any good for the morale of you or your team, if you walk around feeling like the team has failed because you’ve got a backlog of tech debt. As long as it’s not excessive, and you’ve got a plan to properly manage it, there’s nothing wrong or abnormal with tech debt.<figure><img alt="" src="https://miro.medium.com/max/500/0*s1i1jOxtLxzZd4fH.gif" width="267" height="200"></figure>Set benchmarks and keep track. The key to properly managing tech debt is to make sure you’re keeping a proper eye on it. That means setting soft deadlines on what needs to be caught up on and when. This also involves planning ahead, and understanding that you’ll need to allow your developers some time to go back over completed work and clean up bad code, or make updates in line with evolving tech/requirements.This is why having a collaborative and adaptable roadmap early on in development is so important.By making sure you keep your deliberate tech debt properly tracked, whilst simultaneously understanding that accidental tech debt is inevitable and will need to be addressed, you keep your development team accountable andKeep communication open and useful. It’s easy to label what you’re up to as ‘working through the tech debt’, but that doesn’t accurately convey what you and your teams are working on. Also, the word ‘debt’ has negative connotations, and also won’t really make any sense to your less-technical stakeholders.Try to communicate what your teams are working on, how they’re fixing it, and how it’ll make the end product better.<h1 data-selectable-paragraph="">What If I’m Not Technical Enough To Be a Product Manager?</h1>Many Product Managers come from a software engineering background, and software development by nature is very technical. So it’s no wonder that a pervasive myth surrounding Product Management is that you need to be incredibly tech-savvy to work in the industry. Not true!We’ve been over it before in our article: <a href="https://productschool.com/blog/product-management-2/5-product-management-myths-busted/?utm_source=medium&amp;utm_medium=medium&amp;utm_campaign=WeeklyArticles" rel="noopener ugc nofollow" dir="ltr">5 Product Management Myths…Busted!</a>While some particular companies require a computer science degree and a higher level of technical knowledge (usually Google, Apple, and Microsoft) there are many many more companies who only require an interest in technology and a willingness to learn what’s necessary. Most PMs won’t ever have to write a single line of code.When it comes to tech know-how, so long as you are computer literate enough to work at a tech company (eg, comfortable enough with business intelligence tools and general communication platforms like Slack), and are hungry to learn whatever your new role will require of you, soft skills are significantly more important.I’m Carlos González, CEO at Product School, and I enjoy sharing weekly tips for Product leaders!Are you interested in Product Management? Check out <a href="https://www.productschool.com/product-management-certification/?utm_source=medium&amp;utm_medium=medium&amp;utm_campaign=WeeklyArticles" rel="noopener ugc nofollow" dir="ltr">our certifications here</a>. Looking for a good read? Because we’ve launched “<a href="https://www.productschool.com/ship-it-book/?utm_source=medium&amp;utm_medium=medium&amp;utm_campaign=WeeklyArticles" rel="noopener ugc nofollow" dir="ltr">Ship It</a>” as a free resource.This article was also published on <a href="https://www.productschool.com/blog/?utm_source=medium&amp;utm_medium=medium&amp;utm_campaign=WeeklyArticles" rel="noopener ugc nofollow" dir="ltr">The Product Management Blog</a>.

When you’re just getting started in Product Management, there’s a mind-boggling amount of new terms and and theories to come to grips with, especially if you’ve never worked in the tech industry…

career

Career

product

Product & Design

When you’re just getting started in Product Management, there’s a mind-boggling amount of new terms and and theories to come to grips with, especially if you’ve never worked in the tech industry before.

If you’ve come from an engineering background you’re already very familiar with today’s topic: technical debt . But if you’ve come from marketing or any of the other myriad background Product Managers typically come from, you might be scratching your head.

That’s what we’re here for! To break it down and make it easy, and today we’re lifting the lid on technical debt.

The Basics: What Does ‘Technical Debt’ Mean?

Technical debt (known colloquially as tech debt, code debt, or design debt) describes a situation when code quality is sacrificed in exchange for a speedier delivery. Development teams will take steps to push out a new feature, because it’s more important to deliver it quickly than perfectly. The expectation is that there will be time to fix the code or release an update later.

The tech debt metaphor is essentially shorthand for “release now, fix later.”

To the uninitiated, this looks like a terrible idea. Why on Earth would you ever want to compromise software quality for a speedier release?! Doesn’t that sound like a recipe for disaster? But it’s actually a strategic decisions, made when time is of the essence. It doesn’t mean ‘always ship bad code in the interest of speed.’

The debt metaphor was first coined by Ward Cunningham, <a href="https://productschool.com/blog/product-management-2/skills/agile/agile-development-everyone-talking/?utm_source=medium&utm_medium=medium&utm_campaign=WeeklyArticles">one of the authors of the Agile Manifesto </a>. In 1992 Ward said;

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.”

“When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs Technical Debt. This debt decreases productivity. This loss of productivity is the interest of the Technical Debt.”

Ward has explained his debt metaphor in a few different ways over the years,<a href="https://www.agilealliance.org/introduction-to-the-technical-debt-concept/">the best of which you can see right here. </a>

Technical debt doesn’t just refer to deliberate tech debt, but also to accidental and bit rot tech debt, which we’ll go into in more detail. These types of debt aren’t planned, but they are often part and parcel of product development, and something which Product Managers need to take into account.

There are three main types of tech debt, which you’ll likely encounter in your Product Management career.

Dag Liodden, CTO of of Tapad, described deliberate tech debt perfectly in his talk for <a href="https://firstmarkcap.com/">FirstMark </a>. He says that engineers know the right way to do things, and the quick way to do things. “ We sometimes deliberately incur tech debt to reduce time to market.”

Tech debt isn’t always a deliberate decision. It can be a by-product of evolving technology and changes in requirements.

Business goals may shift, a competitor may innovate in the same space as you, or new data may challenge your assumptions. There are a number of scenarios which could render a feature you’ve been working on redundant.

Accidental tech debt often occurs from situations that are out of your control. What matters more is how you respond to them.

Bit rot tech debt is the one you should try to avoid the most. <a href="https://www.wired.com/beyond-the-beyond/2018/02/bit-rot-tech-debt/">According to Wired </a>it involves, “a component or system slowly devolves into unnecessary complexity through lots of incremental changes, often exacerbated when worked upon by several people who might not fully understand the original design.”

This is what happens when you have ‘too many cooks in the kitchen.’ When individual developers work on the product without coming together to look at the big picture, sometimes the individual contributions don’t quite fit together.

Managing technical debt is a key part of a Product Manager’s job, and there are a few things that great PMs do to properly manage tech debt, no matter which of the above categories it fits in to.

Realize that it’s normal. Sometimes it feels like it’s following you around like a bad smell. The key is not to run from it, but to realize that it’s all just part of building products!

It doesn’t do any good for the morale of you or your team, if you walk around feeling like the team has failed because you’ve got a backlog of tech debt. As long as it’s not excessive, and you’ve got a plan to properly manage it, there’s nothing wrong or abnormal with tech debt.

Set benchmarks and keep track. The key to properly managing tech debt is to make sure you’re keeping a proper eye on it. That means setting soft deadlines on what needs to be caught up on and when. This also involves planning ahead, and understanding that you’ll need to allow your developers some time to go back over completed work and clean up bad code, or make updates in line with evolving tech/requirements.

This is why having a collaborative and adaptable roadmap early on in development is so important.

By making sure you keep your deliberate tech debt properly tracked, whilst simultaneously understanding that accidental tech debt is inevitable and will need to be addressed, you keep your development team accountable and

Keep communication open and useful. It’s easy to label what you’re up to as ‘working through the tech debt’, but that doesn’t accurately convey what you and your teams are working on. Also, the word ‘debt’ has negative connotations, and also won’t really make any sense to your less-technical stakeholders.

Try to communicate what your teams are working on, how they’re fixing it, and how it’ll make the end product better.

What If I’m Not Technical Enough To Be a Product Manager?

Many Product Managers come from a software engineering background, and software development by nature is very technical. So it’s no wonder that a pervasive myth surrounding Product Management is that you need to be incredibly tech-savvy to work in the industry. Not true!

We’ve been over it before in our article: <a href="https://productschool.com/blog/product-management-2/5-product-management-myths-busted/?utm_source=medium&utm_medium=medium&utm_campaign=WeeklyArticles">5 Product Management Myths…Busted! </a>

While some particular companies require a computer science degree and a higher level of technical knowledge (usually Google, Apple, and Microsoft) there are many many more companies who only require an interest in technology and a willingness to learn what’s necessary. Most PMs won’t ever have to write a single line of code.

When it comes to tech know-how, so long as you are computer literate enough to work at a tech company (eg, comfortable enough with business intelligence tools and general communication platforms like Slack), and are hungry to learn whatever your new role will require of you, soft skills are significantly more important.

I’m Carlos González, CEO at Product School, and I enjoy sharing weekly tips for Product leaders!

Are you interested in Product Management? Check out <a href="https://www.productschool.com/product-management-certification/?utm_source=medium&utm_medium=medium&utm_campaign=WeeklyArticles">our certifications here </a>. Looking for a good read? Because we’ve launched “<a href="https://www.productschool.com/ship-it-book/?utm_source=medium&utm_medium=medium&utm_campaign=WeeklyArticles">Ship It </a>” as a free resource.

This article was also published on <a href="https://www.productschool.com/blog/?utm_source=medium&utm_medium=medium&utm_campaign=WeeklyArticles">The Product Management Blog </a>.

What Is Technical Debt?

Technical Debt: “Release Now, Fix Later”

Different Types of Technical Debt

Technical Debt for Product Managers

Heather Burton's ideas are part of this journey:

Related collections

Similar ideas