What Is Value?(dwyer.co.za)
dwyer.co.za
What Is Value?
https://dwyer.co.za/what-is-value.html
38 comments
Price is the quantitative indication of value.
"A cynic is someone who knows the price of everything and the value of nothing." :)
An established relationship is value, where instead of just sunk costs, you have solved a lot of the problems that most relationships need to solve, and you can focus on just making it beneficial to all involved. At a large enterprise scale, an established process is value because it is stable and can become the foundation for other processes.
When I identify something as value, I mean that it either creates or resolves tension in a dynamic or conflict of some kind, which creates opportunity in the form of new potential. When I say "super valuable," I mean it appears to have opportunity with nonlinear upside.
Price is one of the most interesting qualities of things to think about, as in a way, it's the resolution of separately held beliefs suspended in an super position. There is a "true" price that is the unity of these ideas, and then there is the settling price that it clears at, where all those other factors collapse into it. Negotiation is the art of discovering how close you can get the clearing price to the abstract true price as possible. It's weird, but approaching negotiations as empirical price discovery is an immensely powerful bargaining position.
An established relationship is value, where instead of just sunk costs, you have solved a lot of the problems that most relationships need to solve, and you can focus on just making it beneficial to all involved. At a large enterprise scale, an established process is value because it is stable and can become the foundation for other processes.
When I identify something as value, I mean that it either creates or resolves tension in a dynamic or conflict of some kind, which creates opportunity in the form of new potential. When I say "super valuable," I mean it appears to have opportunity with nonlinear upside.
Price is one of the most interesting qualities of things to think about, as in a way, it's the resolution of separately held beliefs suspended in an super position. There is a "true" price that is the unity of these ideas, and then there is the settling price that it clears at, where all those other factors collapse into it. Negotiation is the art of discovering how close you can get the clearing price to the abstract true price as possible. It's weird, but approaching negotiations as empirical price discovery is an immensely powerful bargaining position.
I personally think it is one quantitative indication of value. For a same widget at a unique retail price, multiple customer can find different value. It will depend on many parameters, sometime mesurable, but not always.
An exemple : a new camera has the same retail price for an influencer as for an hobbyist.
The hobbyist might find a lot of value, but will mesure it by the number of picture taken or the time spent with the camera, which it will find enjoyable.
The influencer may find no measurable value by upgrading its equipment, but consumers will enjoy more its pictures and therefore it will help to build a more powerful brand.
Price is only one metric.
So what’s the $ value of being in love?
This article seems to be conflating two separate matters: making something valuable, and doing something valuable.
In a business economics sense, to create value is to create something that “other people” care about. Engineers create value by meeting customer requirements and doing so at the lowest cost and of sufficient quality. This value is shared between the customer and the business. The customer is satisfied, and the business makes a profit.
Things that are valuable to the engineer such as personal gain, entertainment, skill-building, job satisfaction, resume building, learning new programming languages, work-life balance, etc. are not necessarily part of the economic value equation. These are rather part of the business employment relationship and the way that the job is done. The engineer may be able to share in the economic value in the form of a higher wage or a bonus; but this will only happen if the customer is satisfied first.
tl;dr creating value is an business economics matter, doing something valuable is an personal and/or employment matter.
In a business economics sense, to create value is to create something that “other people” care about. Engineers create value by meeting customer requirements and doing so at the lowest cost and of sufficient quality. This value is shared between the customer and the business. The customer is satisfied, and the business makes a profit.
Things that are valuable to the engineer such as personal gain, entertainment, skill-building, job satisfaction, resume building, learning new programming languages, work-life balance, etc. are not necessarily part of the economic value equation. These are rather part of the business employment relationship and the way that the job is done. The engineer may be able to share in the economic value in the form of a higher wage or a bonus; but this will only happen if the customer is satisfied first.
tl;dr creating value is an business economics matter, doing something valuable is an personal and/or employment matter.
you didn't read the article. the author is not making a distinction between intangible value that's useful to the worker vs value that's useful to the customer. they're making a distinction along the axes of intangible/tangible and short/long term, all of which is measured by usefulness to the customer. they're saying to be careful not to destroy long-term intangible value (that's of use to the future customer) in exchange for short term tangible value (also measured by the customer).
> long term immeasurable value (e.g. tarnishing the company reputation)
This isn't exactly "immeasuable." Balance sheets quite commonly have an entry for "goodwill" and brand/IP valuation is an art in itself. It's clearly difficult to measure, but it can be measured.
On the other hand, while, depending on how liquid the market is for ownership and debt shares in your company, it may be fairly straightforward to place a value on the entire company, with estimates of how to divvy that up getting less clear between individual line items on a balance sheet, attributing that value to specific individuals, roles, and actions is nearly impossible for all but direct salespeople.
This is where the notion of creating value for your customers gets a lot more nebulous. It is entirely possible to actually measure the monetary impact your product and even specific features of that product can make for a customer, and extrapolate that history to estimate the impact of similar products and features, but there is an actual measurement and statistical science to doing this, and almost no one involved in technical project management and certainly not engineers actually have any of the toolsets of accounting and economics to do this, so we mostly just wing it and make guesses based purely on intuition, so we can get back to our real jobs and do what we're actually good at, which is not measuring and estimating value.
And, of course, this gets a lot stupider when you get into government work and nonsense like EVMS, because your customer isn't a profit-making entity that has any monetary value in its operations at all, yet all of our tooling and thinking is based on the premise that value can be quantified via a common medium of exchange and ranked.
This isn't exactly "immeasuable." Balance sheets quite commonly have an entry for "goodwill" and brand/IP valuation is an art in itself. It's clearly difficult to measure, but it can be measured.
On the other hand, while, depending on how liquid the market is for ownership and debt shares in your company, it may be fairly straightforward to place a value on the entire company, with estimates of how to divvy that up getting less clear between individual line items on a balance sheet, attributing that value to specific individuals, roles, and actions is nearly impossible for all but direct salespeople.
This is where the notion of creating value for your customers gets a lot more nebulous. It is entirely possible to actually measure the monetary impact your product and even specific features of that product can make for a customer, and extrapolate that history to estimate the impact of similar products and features, but there is an actual measurement and statistical science to doing this, and almost no one involved in technical project management and certainly not engineers actually have any of the toolsets of accounting and economics to do this, so we mostly just wing it and make guesses based purely on intuition, so we can get back to our real jobs and do what we're actually good at, which is not measuring and estimating value.
And, of course, this gets a lot stupider when you get into government work and nonsense like EVMS, because your customer isn't a profit-making entity that has any monetary value in its operations at all, yet all of our tooling and thinking is based on the premise that value can be quantified via a common medium of exchange and ranked.
The “goodwill” item on a balance sheet is based on how much the company paid for acquisitions above their book value. Since companies get bought for many reasons, it doesn’t mean anything specific about intangible property. It might mean that management overpaid for the acquisition and haven’t written it off yet.
The book value of a company isn’t supposed to match its intrinsic value. It only includes assets that have a clear price.
The book value of a company isn’t supposed to match its intrinsic value. It only includes assets that have a clear price.
>"It's clearly difficult to measure, but it can be measured."
That is a very generous take. It can be estimated or guessed at via proxies, but something like that is not really measurable. It's like measuring the loss of a key employee leaving.
That is a very generous take. It can be estimated or guessed at via proxies, but something like that is not really measurable. It's like measuring the loss of a key employee leaving.
By those standards, nothing can be measured. Everything is measurable only with a degree of uncertainty.
Some things have more uncertainty than others (compared to what the number would be used for) but we have created techniques to deal with that in practise too (hedging, optionality.)
Maybe you have a personal threshold for a level of uncertainty below which things count as measurable and above which they don't, but you're imbuing the word "measure" with subjective characteristics at that part -- not to be confused with its objective meaning.
Some things have more uncertainty than others (compared to what the number would be used for) but we have created techniques to deal with that in practise too (hedging, optionality.)
Maybe you have a personal threshold for a level of uncertainty below which things count as measurable and above which they don't, but you're imbuing the word "measure" with subjective characteristics at that part -- not to be confused with its objective meaning.
For me "measurement" implies known precision, and some straight-forwardness, simplicity and clear repeatability.
Estimation is on the other hand uses measurements as input and has no clear cut path forward. (you must assume some model)
"Chemistry is just applied physics" ("measurement is just estimating via proxy") might be technically correct, but distinction is still very real and usefull.
Estimation is on the other hand uses measurements as input and has no clear cut path forward. (you must assume some model)
"Chemistry is just applied physics" ("measurement is just estimating via proxy") might be technically correct, but distinction is still very real and usefull.
Ah, we get into the old philosophical "what is probability" question.
I'd argue probability is subjective and estimation is mostly unambiguous, therefore the estimation uncertainty is mostly known, thus estimation is a form of measurement.
I can absolutely see how, if you think probability is frequentist/objective or you think there's generally non-uncertain ambiguity in the estimation task, you would disagree.
I'd argue probability is subjective and estimation is mostly unambiguous, therefore the estimation uncertainty is mostly known, thus estimation is a form of measurement.
I can absolutely see how, if you think probability is frequentist/objective or you think there's generally non-uncertain ambiguity in the estimation task, you would disagree.
Value is the net present value of estimated future cash flows, discounted to the present with an appropriate estimated rate (risk free rate + estimated risk premium). It is very hard to compute further out flows (benefits and losses) for most individual employee activities, thus the risk premium should be high, like really high. This results in making the value have short "duration". Ergo, don't be shy about bragging about short term value gains, for the value gains are usually sandcastles.
This is not civil engineering, most of the stuff me or you used 10 years ago has been rewritten and rebuilt, sometimes from scratch, sometimes several times.
Of course, exceptions exist, but remember that exceptions are exceptional - rare.
This is not civil engineering, most of the stuff me or you used 10 years ago has been rewritten and rebuilt, sometimes from scratch, sometimes several times.
Of course, exceptions exist, but remember that exceptions are exceptional - rare.
You make a promising start with some salient points, then jump prematurely to a conclusion without supplying a missing premise.
By that I mean you entirely discount the value of long term value creation, dismissing it as "very hard to compute".
Your analysis could yield significantly more value by pointing to ways that long term value propositions can be evaluated, sold, and balanced for risk.
It's an easier sell than you might assume. Point to examples where it paid off - e.g.
Roslyn Franklin's X-ray Crystallography --> Watson and Crick's DNA --> Genomic sequencing --> mRNA vaccines
Microsoft's Windows development for 3 versions before conditions were right for the GUI to prevail on desktop computers.
Brin and Page captured long term value from Page Rank by waiting to monetise their search business until it had established clear technical leadership by virtue of its reputation for satisfying users.
By that I mean you entirely discount the value of long term value creation, dismissing it as "very hard to compute".
Your analysis could yield significantly more value by pointing to ways that long term value propositions can be evaluated, sold, and balanced for risk.
It's an easier sell than you might assume. Point to examples where it paid off - e.g.
Roslyn Franklin's X-ray Crystallography --> Watson and Crick's DNA --> Genomic sequencing --> mRNA vaccines
Microsoft's Windows development for 3 versions before conditions were right for the GUI to prevail on desktop computers.
Brin and Page captured long term value from Page Rank by waiting to monetise their search business until it had established clear technical leadership by virtue of its reputation for satisfying users.
This makes sense for founders where you can capture some non-trivial percentage of long term value creation. GP's point was that, for employees, this effectively is never a thing so there's no point even worrying about it.
[deleted]
[deleted]
I’ve been writing and writing on abstract ideas regarding theories of values (i.e. axiologies) since 2018 or so. Some people find my essays/blogposts interesting and become followers of sorts. (Most find them incredibly wordy and roundaboutly.)
This is perhaps HN-flavored although I consider it obsolete. https://asemic-horizon.com/2019/03/13/the-wave/
This is maybe a better example of my more contemporary approach. https://asemic-horizon.com/2021/02/10/we-have-never-been-ase...
— edit: those are more about ethics, this may be closer to OP: https://asemic-horizon.com/2021/07/31/zero-chroma-infinity/
This is perhaps HN-flavored although I consider it obsolete. https://asemic-horizon.com/2019/03/13/the-wave/
This is maybe a better example of my more contemporary approach. https://asemic-horizon.com/2021/02/10/we-have-never-been-ase...
— edit: those are more about ethics, this may be closer to OP: https://asemic-horizon.com/2021/07/31/zero-chroma-infinity/
In regards to your second link, I found this quote coming to mind while reading about your linkages to chromaticity:
“Ineluctable modality of the visible: at least that if no more, thought through my eyes. Signatures of all things I am here to read, seaspawn and seawrack, the nearing tide, that rusty boot. Snotgreen, bluesilver, rust: coloured signs. Limits of the diaphane. But he adds: in bodies. Then he was aware of them bodies before of them coloured. How? By knocking his sconce against them, sure. Go easy. Bald he was and a millionaire, maestro di color che sanno. Limit of the diaphane in. Why in? Diaphane, adiaphane. If you can put your five fingers through it it is a gate, if not a door. Shut your eyes and see.” - Ulysses
This too if you dig a little deeper is an allusion to Aristotle’s work. So I would say that many others have also found abstract analogous meaning in the way in which we decipher color and the way in which we decipher the world.
Ha, I also wrote a post on value once. https://azatris.github.io/true-value
A bit weird and philosophical, rather than useful.
A bit weird and philosophical, rather than useful.
I always liked Allen Ward's take on this. In his view, developers have two[1] forms of value-added work:
- Creating schematics for manufacturing[2], and
- Capturing reusable knowledge.
What's interesting is that these two may be thought of as in opposition. Time spend creating reusable knowledge does not directly benefit the customer -- and time spent obsessing over the customer may easily come at the expense of reusable knowledge.
Any methodology used by developers must take this tension into account. Ward suggests a non-authority project leader (like Toyota's chief engineers) whose job it is to deliver the best products in the world. To help them, functional departments do the actual job. But the functional departments are responsible for creating reusable knowledge, not delivering products.
So there will be a constant creative tension between functional department (who want to further their reusable knowledge) and the project leader (who wants the blueprints now, but cannot order anyone to draw them) and from this creative tension and conflicts great products are woven.
[1]: Actually, he mentions a third in passing: building tools for manufacturing. (I guess the software equivalent is tools for ops, or something.)
[2]: In the software world, read this as creating code that the build system can turn into a useful product.
- Creating schematics for manufacturing[2], and
- Capturing reusable knowledge.
What's interesting is that these two may be thought of as in opposition. Time spend creating reusable knowledge does not directly benefit the customer -- and time spent obsessing over the customer may easily come at the expense of reusable knowledge.
Any methodology used by developers must take this tension into account. Ward suggests a non-authority project leader (like Toyota's chief engineers) whose job it is to deliver the best products in the world. To help them, functional departments do the actual job. But the functional departments are responsible for creating reusable knowledge, not delivering products.
So there will be a constant creative tension between functional department (who want to further their reusable knowledge) and the project leader (who wants the blueprints now, but cannot order anyone to draw them) and from this creative tension and conflicts great products are woven.
[1]: Actually, he mentions a third in passing: building tools for manufacturing. (I guess the software equivalent is tools for ops, or something.)
[2]: In the software world, read this as creating code that the build system can turn into a useful product.
> Software engineers are craftsman.
Software engineers are engineers.
In a discussion specifically about positioning one’s work as being more economically valuable, IMO that’s a distinction worth making.
Software engineers are engineers.
In a discussion specifically about positioning one’s work as being more economically valuable, IMO that’s a distinction worth making.
Traditionally the division of labour between engineers and craftsman has been, the engineer is a knowledge worker who makes the "design", which is then physically produced by the craftsman.
In software this distinction breaks down - the "design" _is_ the finished product. It's really a different kind of thing.
Construction offers a better analogy: the architect produces a high-level design, and the builder is responsible for construction, which includes the full detailed design (which is usually not written down anywhere but manifested in the finished product).
In software this distinction breaks down - the "design" _is_ the finished product. It's really a different kind of thing.
Construction offers a better analogy: the architect produces a high-level design, and the builder is responsible for construction, which includes the full detailed design (which is usually not written down anywhere but manifested in the finished product).
This subject is further complicated by the fact that not everyone who actually "builds the thing" is a craftsman.
Craftsmen are generally high-level experts, because they are involved in craft production. Craft production means producing small numbers of highly customised things. One craftsman can often produce the entire thing from primitives. Craft production is not about precise tolerances and interchangeability; craft production is about sanding down this particular component until the fit is perfect for the specific one-off purpose. Did I mention this is very expensive and not reusable at all?
This is in contrast to e.g. mass production where interchangeability and huge volume and a single model ("any colour as long as it's black") rules. The mass production worker isn't drawing on a long and wide experience; they do a job that was designed to be learnt in a few days, and they do it over and over. No feedback cycles are designed into the system. You can make defective parts for hours or days and nobody will notice -- and it's probably best if you keep quiet about it, too. The important thing is that you produce your daily volume, defective or not. Mass production is all about local optimisation at the cost of system performance. But hey, it's cheaper than craft production! (And the output is correspondingly shoddier.)
Then lean production aims for the huge volumes of mass production, except by optimising the entire system instead of local tasks. Books have been written about this so I won't but the end product often costs less than the mass produced, and can also be of higher quality than the craft produced.
I bring this up because as quaint as craftsmen are, if our goal is to be like craft production we'll drive up costs and be outcompeted by someone who realises that craft production isn't all that hot other than for very specific up-scale purposes, where cost is a feature.
Craftsmen are generally high-level experts, because they are involved in craft production. Craft production means producing small numbers of highly customised things. One craftsman can often produce the entire thing from primitives. Craft production is not about precise tolerances and interchangeability; craft production is about sanding down this particular component until the fit is perfect for the specific one-off purpose. Did I mention this is very expensive and not reusable at all?
This is in contrast to e.g. mass production where interchangeability and huge volume and a single model ("any colour as long as it's black") rules. The mass production worker isn't drawing on a long and wide experience; they do a job that was designed to be learnt in a few days, and they do it over and over. No feedback cycles are designed into the system. You can make defective parts for hours or days and nobody will notice -- and it's probably best if you keep quiet about it, too. The important thing is that you produce your daily volume, defective or not. Mass production is all about local optimisation at the cost of system performance. But hey, it's cheaper than craft production! (And the output is correspondingly shoddier.)
Then lean production aims for the huge volumes of mass production, except by optimising the entire system instead of local tasks. Books have been written about this so I won't but the end product often costs less than the mass produced, and can also be of higher quality than the craft produced.
I bring this up because as quaint as craftsmen are, if our goal is to be like craft production we'll drive up costs and be outcompeted by someone who realises that craft production isn't all that hot other than for very specific up-scale purposes, where cost is a feature.
Software engineers design and codify processes; those processes are carried out by computers. If you've worked long enough (or are unlucky enough) you may have had to design accompanying business processes that were carried out by humans as well, e.g. all analysts must upload their work in format x by Thursday night and start the batch processes, or else.
I hate the craftsman trope. In my view baked in is the idea we're somehow more creative or special than other engineers, and worse less bound by principles of math and science. It simultaneously denigrates those other engineering disciplines and primes software engineers with a really bad intuition about the proper way to carry out their work.
I don't mean to pick on you or the original author, it's a widely held idea pushed by some very influential figures, I just think it's in desperate need of reexamination.
I hate the craftsman trope. In my view baked in is the idea we're somehow more creative or special than other engineers, and worse less bound by principles of math and science. It simultaneously denigrates those other engineering disciplines and primes software engineers with a really bad intuition about the proper way to carry out their work.
I don't mean to pick on you or the original author, it's a widely held idea pushed by some very influential figures, I just think it's in desperate need of reexamination.
Software Engineers design and build digital “factories” that (when run) automate information tasks.
This seems overly complex. If you change the state of the world from X to Y, and Y is the preferred state, then you have created value.
One may say "who says Y is preferred over X?". And it's a legit question. The question is, have you created value or not?
One may say "who says Y is preferred over X?". And it's a legit question. The question is, have you created value or not?
If I hold my girlfriend's hand and she likes it more I would not say I have created value
I strongly disagree with this assertion.
I have no reasoning. It’s just clear to me that it is true (though I don’t expect or need anyone to agree)
I have no reasoning. It’s just clear to me that it is true (though I don’t expect or need anyone to agree)
Try asking your girlfriend whether she thinks holding her hand is worthless :-) Making someone happy (-ier) is a great, canonical example of creating value.
People will tolerate surprising levels of discomfort, even financial loss, to be physically close with other people.
I'd say this basic need goes even further than humans. Certainly at least mammals, with their complex endocrinological and social systems; but possibly any organism that procreates via sex.
People will tolerate surprising levels of discomfort, even financial loss, to be physically close with other people.
I'd say this basic need goes even further than humans. Certainly at least mammals, with their complex endocrinological and social systems; but possibly any organism that procreates via sex.
> Try asking your girlfriend whether she thinks holding her hand is worthless
but value and worth are not the same thing ?
but value and worth are not the same thing ?
There are "boyfriend pillows" [0] that partially fulfil the feeling of being cuddled/held by a boyfriend. They sell well, apparently.
I imagine that if you could do the same for a "boyfriend hand-holder" product that partially fulfils the feeling of having your hand held, it would also sell well.
If this happened, no-one would say that the product had no value. Yet the product is only capturing part of the value of actually having a boyfriend hold your hand.
Therefore I would say that you definitely have created value by holding your girlfriend's hand.
[0] https://www.reviewed.com/lifestyle/features/boyfriend-pillow...
I imagine that if you could do the same for a "boyfriend hand-holder" product that partially fulfils the feeling of having your hand held, it would also sell well.
If this happened, no-one would say that the product had no value. Yet the product is only capturing part of the value of actually having a boyfriend hold your hand.
Therefore I would say that you definitely have created value by holding your girlfriend's hand.
[0] https://www.reviewed.com/lifestyle/features/boyfriend-pillow...
In my mind you've created value.
I'm told some people pay prostitutes to just hang out with them to feel some sense of intimacy, without even having sex. Ie, people are basically being paid to hold hands.
I'm told some people pay prostitutes to just hang out with them to feel some sense of intimacy, without even having sex. Ie, people are basically being paid to hold hands.
When I first read the title I was thinking it would be more philosophical, but I liked the article. It provides a good vocabulary to use when trying to discuss with my product manager why we shouldn’t just get this “feature done real quick”.
> you might have figured out that changing your Resume from using phrases like “I worked on a Java codebase of around 100k LoC, using Spring and React” to ones more like “I built a widget-shipping feature that shipped 300k widgets and ultimately created $1 million in business value” is a good way of ‘creating value’ in concrete sense of a higher paying job.
Is that actually true, in other people's experience? I would have thought that most people involved in tech hiring would prefer the first version — at least it tells me what technologies you're familiar with. The second one just tells me what somebody else did with your code. Sure, they sold a lot of widgets, but I'd guess that has a lot more to with the quality of the widget than with the quality of your software
Is that actually true, in other people's experience? I would have thought that most people involved in tech hiring would prefer the first version — at least it tells me what technologies you're familiar with. The second one just tells me what somebody else did with your code. Sure, they sold a lot of widgets, but I'd guess that has a lot more to with the quality of the widget than with the quality of your software
I can't speak for others, but as a hiring manager I prefer the latter because:
* It suggests the person understands the bigger picture behind what they're doing (rather than just "punching tickets")
* If your code sits in a 'financial critical path', this usually implies stricter requirements in your engineering in some respects -- you'll probably have had to think harder about reliability, cover more edge cases & co-ordinate with others more around requirements
* It suggests the person understands the bigger picture behind what they're doing (rather than just "punching tickets")
* If your code sits in a 'financial critical path', this usually implies stricter requirements in your engineering in some respects -- you'll probably have had to think harder about reliability, cover more edge cases & co-ordinate with others more around requirements
I also prefer the second. Tech specifics aren’t anywhere near as important as the ability to be part of a team that finds value.
If you are a perfect fit tech skills-wise and can’t think/talk about the business side, you can make progress on our ticket backlog (and so we can still hire you), but if you’re moderately skilled at software in general but can connect that to the business problems, we can definitely use in a variety of spots.
If you are a perfect fit tech skills-wise and can’t think/talk about the business side, you can make progress on our ticket backlog (and so we can still hire you), but if you’re moderately skilled at software in general but can connect that to the business problems, we can definitely use in a variety of spots.
I think the author swapped LI and IL in either the diagram or the text.