Often, it's hard for us to understand the difference between OUR goals and THEIR goals. In the mentioned presentation - I might think that of course the VP R&D will want to remove technical debt!
To properly communicate it, we first need to understand what drives the other person - what are the measured on? How do they define success in their role?
Love the practical example, John and the lessons in the article. This seems to be a hot-topic (I'm actually planning to do something similar in this weeks' HGE article).
I was wondering what recommendation you'd have for getting data on things such as "the impact of tech debt" when those are traditionally hard to quantify.
For example, if its a generally agreed upon thing that a particular area of the code is "bad", compared to the new system, but at the end of the day every developers time working in any area will be different and the general expectation is we shouldn't be shipping bugs regardless of what area you work in, how can we say with definitiveness what the impact will be of cleaning up the code in that area?
This is where having estimates can help. For example if your estimates to add features to this area are always [more] wrong than elsewhere or X% bigger than elsewhere that provides some indication.
The same for defects, if more of your defects occur in the area or occur as a result of changing the area that gives an indication.
The real trick is to then tie this data back to the delay, risk and cost of the work or defects.
Often, it's hard for us to understand the difference between OUR goals and THEIR goals. In the mentioned presentation - I might think that of course the VP R&D will want to remove technical debt!
To properly communicate it, we first need to understand what drives the other person - what are the measured on? How do they define success in their role?
Great article!
Very true. They may share our goals and have other high priority goals.
It is so important to speak the language of your audience. Also it is critical for engineers to think about the company's goal vs their own goals!
Your post covers that so well.
Thanks Raviraj.
Love the practical example, John and the lessons in the article. This seems to be a hot-topic (I'm actually planning to do something similar in this weeks' HGE article).
I was wondering what recommendation you'd have for getting data on things such as "the impact of tech debt" when those are traditionally hard to quantify.
For example, if its a generally agreed upon thing that a particular area of the code is "bad", compared to the new system, but at the end of the day every developers time working in any area will be different and the general expectation is we shouldn't be shipping bugs regardless of what area you work in, how can we say with definitiveness what the impact will be of cleaning up the code in that area?
This is where having estimates can help. For example if your estimates to add features to this area are always [more] wrong than elsewhere or X% bigger than elsewhere that provides some indication.
The same for defects, if more of your defects occur in the area or occur as a result of changing the area that gives an indication.
The real trick is to then tie this data back to the delay, risk and cost of the work or defects.