4 ms·

Yes, business stakeholders often mistrust software and IT people, because relative to other industries we do a poor job of meeting our commitments. McKinsey di

Yes, business stakeholders often mistrust software and IT people, because relative to other industries we do a poor job of meeting our commitments. McKinsey did a study recently which found that large IT projects ran on average 45 percent over budget and delivered 56 percent less value than expected [1]. An executive is interacting with people from multiple industries or business functions and this is on the high side. It's much worse than a function like accounting, and it's also worse than many industries with bad reputations, like construction. So over time they are going to come to regard estimates from the tech guys with more suspicion than most. To the extent that other industries have this problem, yes you will find similar trust issues. If you are a PM/product manager then the best way to handle technical debt is to focus on the benefits that come from paying it down. You are not scheduling time for technical debt, you are scheduling time to improve reliability, security, scalability, etc. and from day one you are lobbying for more time to do every feature so that it's done right in the first place. Yes, sometimes one of these things has to go wrong before the business people start listening, but if you were calling it out from day one they will respect your input that much more. If you are a developer it's important to understand what work has business value and what doesn't, and make or inform decisions appropriately. Frankly there are developers out there whose attitude amounts to "Your job is to pay my salary, my job is to make whatever technical decisions I want without oversight, and if we don't deliver on time/on budget it's not my problem." Not all tech debt is worth paying down, the decision generally should be made based on the "interest rate" of the debt (how hard is this going to burn us in the long run?) and the term length of the "loan" (will this component be around for one year or ten?). [1] https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value https://www.mckinsey.com/business-functions/mckinsey-digital...

watwut 7y ago
> McKinsey did a study recently which found that large IT projects ran on average 45 percent over budget and delivered 56 percent less value than expected [1]. Is that fault of IT people or rather did business people over-promised? Because my repeated experience is that we give estimates, they are considered big and shorter estimates are sold. And it has nothing to do with IT people over-promising. I have yet to see a team where it is tech people pushing for shorter deadline and management being like "yeah, it is too risky, lets go with bigger estimate". There are situations of me making short estimate, but I also make estimates too big in other situations. However, somehow the estimate that makes its way toward contract is always short due to negotiating pressure. PM are all too often non-technical, it is quite unfair to blame "IT people" on mistakes of general management and project management. Project management blaming the these contracts being basically frauds on anyone else then themselves is literally them blaming scapegoats for their own faults.
pytester 7y ago
This approach fails spectacularly. The benefits of paying down tech debt are often massive but they are extremely diffuse (i.e. they tend to affect everything in a small way) and hard to recognize (good luck proving that feature X that hasn't even been dreamed up yet will take 16 days instead of 25 because of Y refactoring you're doing now). Every time I've ever seen the approach of "create a business case for each refactoring" put into practice it has made the problem spectacularly worse because the developers are reluctant to manufacture sales pitches for things where the payoff is hard to recognize. Hell, developers are reluctant to manufacture sales pitches period. They're typically awful salespeople. If they're good at making business cases, and few are, they're probably not working for you. Making the quality of your product contingent on the skills of your developers at creating sales pitches is a brain dead own goal. The best approach is to hire good engineers, allocate a rough proportion of their time that proxies the level of quality you want (e.g. 30%) and trust them - let them figure out how to allocate that time. Coz if you can't trust them you're probably fucked anyway. >If you are a developer it's important to understand what work has business value and what doesn't, and make or inform decisions appropriately. Frankly there are developers out there whose attitude amounts to "Your job is to pay my salary, my job is to make whatever technical decisions I want without oversight, and if we don't deliver on time/on budget it's not my problem." I can't begin to explain how incredibly damaging this attitude is. It's the philosophy of a micromanager. Seriously, anybody who wants technical oversight of developer decisions should either become a developer or they should fuck off.

watwut 7y ago

> McKinsey did a study recently which found that large IT projects ran on average 45 percent over budget and delivered 56 percent less value than expected [1]. Is that fault of IT people or rather did business people over-promised? Because my repeated experience is that we give estimates, they are considered big and shorter estimates are sold. And it has nothing to do with IT people over-promising. I have yet to see a team where it is tech people pushing for shorter deadline and management being like "yeah, it is too risky, lets go with bigger estimate". There are situations of me making short estimate, but I also make estimates too big in other situations. However, somehow the estimate that makes its way toward contract is always short due to negotiating pressure. PM are all too often non-technical, it is quite unfair to blame "IT people" on mistakes of general management and project management. Project management blaming the these contracts being basically frauds on anyone else then themselves is literally them blaming scapegoats for their own faults.

pytester 7y ago

This approach fails spectacularly. The benefits of paying down tech debt are often massive but they are extremely diffuse (i.e. they tend to affect everything in a small way) and hard to recognize (good luck proving that feature X that hasn't even been dreamed up yet will take 16 days instead of 25 because of Y refactoring you're doing now). Every time I've ever seen the approach of "create a business case for each refactoring" put into practice it has made the problem spectacularly worse because the developers are reluctant to manufacture sales pitches for things where the payoff is hard to recognize. Hell, developers are reluctant to manufacture sales pitches period. They're typically awful salespeople. If they're good at making business cases, and few are, they're probably not working for you. Making the quality of your product contingent on the skills of your developers at creating sales pitches is a brain dead own goal. The best approach is to hire good engineers, allocate a rough proportion of their time that proxies the level of quality you want (e.g. 30%) and trust them - let them figure out how to allocate that time. Coz if you can't trust them you're probably fucked anyway. >If you are a developer it's important to understand what work has business value and what doesn't, and make or inform decisions appropriately. Frankly there are developers out there whose attitude amounts to "Your job is to pay my salary, my job is to make whatever technical decisions I want without oversight, and if we don't deliver on time/on budget it's not my problem." I can't begin to explain how incredibly damaging this attitude is. It's the philosophy of a micromanager. Seriously, anybody who wants technical oversight of developer decisions should either become a developer or they should fuck off.