4 ms·

There's a reason the execs thinks in terms of revenue, cost, and profit. Why would you want your engineers, designers, or anyone abstracted away from that? From

There's a reason the execs thinks in terms of revenue, cost, and profit. Why would you want your engineers, designers, or anyone abstracted away from that? From my experience, every time you try to do that you end up with the business and the workforce misaligned. It's not always easy to quantify value, and sometimes the return on an investment is slow and that can be unattractive. However, that doesn't mean we should try and hide away from figuring out the true value of work in business terms. In my opinion, we should judge the impact and effectiveness on the base line metrics as the rest of the org. In a for profit company that's measures such as increasing customer spend, increasing conversion rates, reducing churn, reducing operational costs. All of those measures can be directly tied to revenue, costs, and profit. It's the language the business speaks, why would you want to speak a different language to the rest of the business? More than that, why would you want to start measuring performance in a different way to the rest of the business?

Spivak 6y ago
Because, although it oughtn't, the culture that way of thinking produces some of the worst code because it's more difficult to quantify the direct value of a lot of the work that goes into good software engineering. Security ends up just being a cost, nobody bothers to actually quantify the risk because nobody really knows. This leads down the path of "the only security that's quantifiable are my legal requirements." You can't know the productivity gains/losses from a refactor until long after you've done it. You can't know how productive different ecosystems are until long after your team adopted them. Your only measuring stick is how excited your devs are to use it. What's productive for one team might not be for another. Nobody quantifies acquiring tech debt so it piles up while people "deliver" and the productivity losses come so gradually from it that teams don't even realize they've slowed down because their velocity says constant it's just that cards gradually get more difficult. Performance becomes a cost because there's a huge grey area (Jira) between "so slow I consider it down" and "general annoyance that slowly nudges me away from the product." Unless you're planet scale or whatever your sample size isn't big enough to notice these things. This way of thinking creates feature factories. I agree 100% that we can do better than being totally disconnected from the business but this ends up being so much worse.
- bluehatbrit 6y ago
  I do not disagree that it's really tough to quantify a lot of those things and most of them will be estimates and may be wrong, in particular over longer periods of time. But in the context of the article (a larger business with profit generating goals) I don't think you can walk up to management and say "lets switch technology, we're excited about this new thing" and expect to be taken seriously. It's not dissimilar for security and code quality, they are just part of doing the job properly. They're also part of continually identifiying future business risk. If you find a vulnerability you can absolutely identify the risk of leaving it there, just like you can identify the level of risk of not thinking about it up front with a feature. We absolutely can provide estimates to backup why we should tackle some tech debt, it may not be incredibly accurate but if you're unable to estimate any gain from tackling it, is it really a problem? When you see a security issue you've got legal risk and brand reputation risk. Both of those are very tangible, while they're not easy to estimate and there's a lot of room for error I don't know many businesses that would rather take the risk of EU data breach fines vs paying an engineer to spend a few days fixing it. That doesn't lead to feature factories, it leads to informed decisions. Sometimes the business is going to choose to take on the risk of slower development in an area if they think they're unlikely to revisit it vs doing a refactor. Sometimes they may also take on a risk of security issues if they feel it's outside of their threat model. It's up to us as product/engineering teams to give a clear picture and side our professional advice in a way they can understand. In many cases we may need to push to do a refactor or learn a new technology, but we can't expect to persuade someone while we're speaking a different language to them. Saying that they're only interested in business value and that makes them a "feature factory" doesn't make sense in that regard. Perhaps the business and leadership really enjoy the taste of risk, and if that's the case then trying to qualify value in some other language still won't help. There we have a larger problem with the practices of the leadership and company as a whole. I agree that the areas you've mentioned are ones where it's hard to qualify value in terms the business understands, but it doesn't mean the system is broken. It's the language used to describe the goals of the organisation. If you're lucky enough to work in a company which places a goal as team happiness as well then you can also speak in those terms in some cases. However, in the context of the article (Atlassian) I struggle to understand why a team lead would try to abstract away the core business value a team is generating. A team leader should be rushing to quantify it as accurately and clearly as possible to give the team a leg up in the orgs career ladder.

Spivak 6y ago

Because, although it oughtn't, the culture that way of thinking produces some of the worst code because it's more difficult to quantify the direct value of a lot of the work that goes into good software engineering. Security ends up just being a cost, nobody bothers to actually quantify the risk because nobody really knows. This leads down the path of "the only security that's quantifiable are my legal requirements." You can't know the productivity gains/losses from a refactor until long after you've done it. You can't know how productive different ecosystems are until long after your team adopted them. Your only measuring stick is how excited your devs are to use it. What's productive for one team might not be for another. Nobody quantifies acquiring tech debt so it piles up while people "deliver" and the productivity losses come so gradually from it that teams don't even realize they've slowed down because their velocity says constant it's just that cards gradually get more difficult. Performance becomes a cost because there's a huge grey area (Jira) between "so slow I consider it down" and "general annoyance that slowly nudges me away from the product." Unless you're planet scale or whatever your sample size isn't big enough to notice these things. This way of thinking creates feature factories. I agree 100% that we can do better than being totally disconnected from the business but this ends up being so much worse.

bluehatbrit 6y ago
I do not disagree that it's really tough to quantify a lot of those things and most of them will be estimates and may be wrong, in particular over longer periods of time. But in the context of the article (a larger business with profit generating goals) I don't think you can walk up to management and say "lets switch technology, we're excited about this new thing" and expect to be taken seriously. It's not dissimilar for security and code quality, they are just part of doing the job properly. They're also part of continually identifiying future business risk. If you find a vulnerability you can absolutely identify the risk of leaving it there, just like you can identify the level of risk of not thinking about it up front with a feature. We absolutely can provide estimates to backup why we should tackle some tech debt, it may not be incredibly accurate but if you're unable to estimate any gain from tackling it, is it really a problem? When you see a security issue you've got legal risk and brand reputation risk. Both of those are very tangible, while they're not easy to estimate and there's a lot of room for error I don't know many businesses that would rather take the risk of EU data breach fines vs paying an engineer to spend a few days fixing it. That doesn't lead to feature factories, it leads to informed decisions. Sometimes the business is going to choose to take on the risk of slower development in an area if they think they're unlikely to revisit it vs doing a refactor. Sometimes they may also take on a risk of security issues if they feel it's outside of their threat model. It's up to us as product/engineering teams to give a clear picture and side our professional advice in a way they can understand. In many cases we may need to push to do a refactor or learn a new technology, but we can't expect to persuade someone while we're speaking a different language to them. Saying that they're only interested in business value and that makes them a "feature factory" doesn't make sense in that regard. Perhaps the business and leadership really enjoy the taste of risk, and if that's the case then trying to qualify value in some other language still won't help. There we have a larger problem with the practices of the leadership and company as a whole. I agree that the areas you've mentioned are ones where it's hard to qualify value in terms the business understands, but it doesn't mean the system is broken. It's the language used to describe the goals of the organisation. If you're lucky enough to work in a company which places a goal as team happiness as well then you can also speak in those terms in some cases. However, in the context of the article (Atlassian) I struggle to understand why a team lead would try to abstract away the core business value a team is generating. A team leader should be rushing to quantify it as accurately and clearly as possible to give the team a leg up in the orgs career ladder.