[HN Gopher] Embrace Complexity; Tighten Your Feedback Loops
___________________________________________________________________
Embrace Complexity; Tighten Your Feedback Loops
Author : lutzh
Score : 108 points
Date : 2023-07-22 11:30 UTC (11 hours ago)
(HTM) web link (ferd.ca)
(TXT) w3m dump (ferd.ca)
| kaycebasques wrote:
| This comment is in reference to the second to last paragraph
| (there's something weird going on with that page that's
| preventing me from copying text on my mobile). That paragraph
| says something like "by being outside silos you can carry
| information around and tie it all together".
|
| I've been thinking about my role as a technical writer (TW)
| recently. I think TWs have a lot of opportunity to operate in a
| similar way. The real name of the game for my line of work is
| organizational knowledge management. For example, I've had some
| [1] success getting Eng teams to dump common Q&A into Stack
| Overflow so that the next time the issue comes up they can just
| link customers to that answer. It often feels a bit more
| lightweight and less intimidating than updating the official
| docs. Also the Q and A nature of Stack Overflow keeps the docs
| request tightly scoped. And of course the end result is that the
| knowledge is much more accessible.
|
| On the other hand, maybe there's nothing special about SREs or
| TWs here and "organizational knowledge management" is the name of
| the game for every role in the org. We all just tackle the
| problem from a different angle.
|
| [1] Emphasis on "some" here. Sometimes it works very well, other
| times it doesn't go anywhere.
| ilaksh wrote:
| A lot of good information.
|
| But my cynical worker viewpoint is that the problem is really
| that upper management doesn't do the actual work and that is by
| design. It's a class separation. They are there to crack the whip
| and collect the spoils.
|
| The only way for upper management to really understand what's
| going on and give useful input would be for them to be directly
| involved on a day-to-day basis.
|
| In other words, they would have to do actual work.
|
| That's not going to happen. So the best they can do is to stay
| out of the way of people who are actually working, avoid making
| decrees, and maybe try to keep the other managers from
| interfering with the work also.
|
| Maybe another approach would be for the workers to share more
| equally in the spoils so that they would be naturally inclined to
| integrate business improvements and goals. But that's never going
| to happen.
|
| The structure is much more directly related to a caste system
| than people may acknowledge.
| TheCowboy wrote:
| I've often encountered software that feels like it was designed
| by people who don't have to use it to do work, and not
| necessarily because they're engaging in class conflict (though
| it can certainly appear that way based on the painfully flawed
| software people can be forced to tolerate).
|
| The worst system was a DOS-based point-of-sale system in a
| restaurant---kept around way beyond the 'age of DOS'. The main
| gimmick is that it had a wired light touch pen (I think it
| worked like a classic Nintendo gun) for selection. It gave the
| illusion of innovation/ease of use, but was extremely
| cumbersome and required a good amount of experience to avoid
| mistakes.
|
| I also think trying to pin down things as strictly class
| warfare every time can muddy problem areas. Institutions
| realistically do gain some functional productivity by having
| people specialize and having defined roles, but having them too
| separated and specialized can also create problems. You can
| also have a lazy human problem, where people don't want to do
| the work that isn't directly associated with their role, and so
| on. There is also a lot in the bschool lit about how different
| business structures contribute to these problems too.
| paulryanrogers wrote:
| Ironic since my experience during the transition away from
| ASCII displays and shortcut inputs is that the touch screens
| and deep menus were slow. Touch won because it was more
| approachable, at least for the shallowest options
| mwerd wrote:
| That's a point of view that would change quickly if you were in
| one of those management positions.
|
| You get to a point where it's impossible to do the work
| anymore. There's too much of it. You have to develop teams,
| processes, structure, etc. that delivers the outcomes you're
| accountable for with full knowledge that you cannot do them
| yourself. It's very different than doing the work and
| experience shows that fewer people are capable of doing it,
| especially with any repeatability. The working world yearns for
| effective managers.
|
| I encourage you to compare the productivity of the modern
| multinational corporation to any commune in history. The people
| working in collectives are not stupid or lazy. It's not an
| effective structure.
| chrisdbanks wrote:
| Agree. In fact one problem many have when new to management
| is actually doing the work themselves rather than coaching
| others to achieve it.
| LapsangGuzzler wrote:
| > I encourage you to compare the productivity of the modern
| multinational corporation to any commune in history. The
| people working in collectives are not stupid or lazy. It's
| not an effective structure.
|
| It's a hard comparison to make when the goals of those two
| systems are vastly different.
|
| I worked for a multinational software company and the amount
| of waste I saw was just staggering. If outside shareholders
| knew how little we actually produced on a day to day basis,
| they would probably be appalled. But because the company knew
| how to engage with market analysts, we looked good on paper.
| So much of the money made today involves just being the
| biggest player in a given market, regardless of how effective
| the product is (i.e. "nobody ever got fired for choosing
| Microsoft")
| AndrewKemendo wrote:
| >They are there to crack the whip and collect the spoils
|
| This is historically correct
|
| Here's a recent unambiguous proof from Tesla's own words:
|
| "Tesla argued that stock options were used to ensure Director's
| incentives were aligned with investor goals." [1]
|
| Said another way, "we massively over-paid directors in order to
| give them an incentive to prioritize investor goals over all
| other goals"
|
| In the parlance of finance this is the only goal and the
| ultimate decision that cannot be questioned.
|
| I have seen this made explicit in multiple organizations as a
| Director or Senior Manager. As a manager, if you are explicit
| in supporting employee benefits over increase in stock price or
| C-Suite direction (when given the choice) then you should
| expect no further growth or promotions (unless you can
| manipulate the org or have some damaging information on the
| company).
|
| >Maybe another approach would be for the workers to share more
| equally in the spoils so that they would be naturally inclined
| to integrate business improvements and goals
|
| The strong form of this is a worker-owned-cooperative but
| second to that are labor unions. So if you want to change it,
| then start/join a union and stop creating corporations with
| separate ownership rules for investors.
|
| [1]https://www.engadget.com/tesla-directors-agree-to-
| return-735...
| chrisdbanks wrote:
| Workers vs investors shouldn't be seen as a zero sum game. If
| it is then that's short-term thinking. Simon Sinek explains
| this all very well in The Infinite Game.
| PartiallyTyped wrote:
| Why should they care about long term health of the company
| when their stake can change [almost] on a whim?
|
| The whole system seems to exist for short term profits.
| slt2021 wrote:
| Any non-zero sum game can be re-formulated in zero-sum game
| terms, this is a rule.
|
| Give me example of any non-zero sum game, and I can prove
| that under the hood it is actually a zero-sum game.
|
| The trivial proof is that profit/revenue pool available for
| Corporation is limited, and the main question is how that
| profit pool is to be divided among Labor (employees) and
| Capital (investors/shareholders).
|
| The fundamental laws of mass/energy preservation equally
| apply to money - you can't create money out of thin air, it
| has to be taken from someone else (customer) and then
| redistributed (among
| suppliers/labor/investors/shareholders/tax man)
| snovv_crash wrote:
| How does this model account for varying growth based on
| employee alignment with company goals?
| slt2021 wrote:
| Think of annual profit generated by company as a fixed
| pie. or total market as a giant pie.
|
| Question is how to slice a pie between Labor and Capital?
|
| Now we know that IT is a growing market, and next year
| pie will be bigger, much bigger. That's why Capital needs
| Labor to cooperate along and work as efficiently as
| possible to capture maximum slice of pie for the
| Corporation next year and the year after.
|
| That's why they give variable compensation and give sense
| of ownership. Just by giving out 0.1% of shares, Capital
| is able to extract max value form Labor and make their
| pie grow at 30-40% per year.
|
| Absolutely killer deal for Capital.
|
| That's how zuckerberg et al become billionaires, while
| employees who created the money making machine are mere
| (multi)millionaires.
|
| you join stage B startup and get 0.01% of company as ISO
| options, but you do the 100% of the work required to make
| product and grow company from $10M valuation to $10B
| valuation. Three orders of magnitude growth for Capital,
| while Labor get 1/1000 of that growth
| admax88qqq wrote:
| > Now we know that IT is a growing market,
|
| That's literally a non zero sum game. You can phrase it
| as cynically as you like, but that's still the definition
| of a non zero sum game.
| slt2021 wrote:
| it is zero sum when it comes to Labor vs Capital
| relationship.
|
| Counter example to your claim: if giving out RSUs is not
| zero-sum, then why don't Companies give me as many RSUs
| as possible, since they are not losing anything and it is
| not zero-sum game, by your definition?
| aschearer wrote:
| Giving and receiving love is not zero-sum. Cultivating
| mutual trust is not zero-sum.
| slt2021 wrote:
| it is not zero-sum between two parties (as in if one
| party shows more love, there is a chance it will create
| more mutual love from the other party).
|
| But, the problem can be reformulated as zero-sum in terms
| of time: Time is the ultimate scarce and zero-sum
| resource, you cannot create time, only redistribute.
|
| The more time we spend with the loved ones, less time we
| have for other things like hobbies and work. Company
| wants people to spend maximum time on work and worker
| efficiency (so called "career growth"), and less time on
| personal life etc. For corporation - worker's attention
| is absolutely zero-sum game and they want maximum of
| worker's attention, on top of 9-5.
|
| That's why they create more employee love by throwing
| benefits, free food and snacks, corporate parties so that
| they spend less time on personal matters and work more
| toward the company's goals.
| AndrewKemendo wrote:
| Simon is wrong.
|
| It is absolutely zero sum for any measure that matters over
| periods that are impactful to individual and familial human
| flourishing
|
| This capitalist rationalization of greed-based markets,
| loves to pick whatever timeline for measurement which fits
| their criteria.
|
| It is unambiguous that wealth and power accumulation will
| persistently concentrate into the smallest number of hands
| in absence of collective structural countermeasures.
|
| So the default state of large scale capatalist systems
| follows power law in both wealth and power distribution.
| It's a mathematical reality that is shown over and over and
| over to repeat itself
| Zetice wrote:
| You're pitching this as truth when in reality it's just
| one viewpoint. Simon is not "wrong" any more than you are
| "wrong". You're just arguing from different perspectives.
| capitalsigma wrote:
| Most big tech firms give engineers RSUs for this reason
| slt2021 wrote:
| also SBC (share based comp) looks favorably on cash flow
| statement, because SBC does not decrease EBITDA, thus
| artificially inflating EBITDA numbers and price target of
| the company.
|
| How this works: new SaaS startup shows up and shows $10M
| EBITDA to investors. This does not reflect $5M in SBC.
|
| According to industry averages, bankers apply average (lets
| say 10x) EBITDA multiple and derive valuation of $100M and
| invest funds based on that calculation.
|
| Had company paid cash salary instead of RSUs, firms' EBITDA
| would have been $5M and valuation of $50M - a half of
| original pitched value
|
| Obviously this is just a naiive textbook example, and
| actual valuations are more complex and involve several ways
| of deriving value and multiples, but in general RSU is
| viewed favorably mainly because it improves Cash Flow from
| Operations and EBITDA numbers - in addition to creating
| incentives to employees
| AndrewKemendo wrote:
| Indeed, which are sub class of stock with no power.
|
| So it's the same story and is effectively a lottery ticket.
| spacephysics wrote:
| To be frank, this has an anti-capitalist smell and I don't feel
| is written in good faith.
|
| Sure there are managers that crack the whip, but most the
| places I've worked for, my manager was a former IC and cared
| deeply about the health of the product, while protecting the IC
| team I was on from the business side.
|
| Learning more about the business portion and product manager
| viewpoints, gives me a more sympathetic tone to the whole
| situation.
|
| We shouldn't expect someone whose career they've focused on the
| business side to understand the software in depth. Sure there's
| space to learn _anything_ , but people have lives outside of
| career. Instead, a healthy company delegates these tasks out.
| It's the responsibility of my manager to have one foot in the
| software, and one in the business, to help best translate and
| champion towards a common goal.
|
| It's the responsibility of her managers to respect the
| decisions she makes, and when hard lines are drawn for the sake
| of the health of the product to adhere to them. Within reason,
| of course.
|
| This to me makes me feel excited to go to work (not every day,
| I'm not a psycho :) ), and makes me want to climb the ladder. I
| get paid well, produce value for the company, and get
| opportunities to work on challenges and with data/systems that
| I otherwise would not be able to.
|
| With that knowledge, I can then take that to my side business
| and more effectively grow it. Don't think there's any "they're
| taking the spoils" going on...
| [deleted]
| tempodox wrote:
| I like the fucking-around/finding-out graph. It looks realistic
| to me (implicitly assuming the right kind of fucking around). And
| yes, tighten your feedback loops.
| GuB-42 wrote:
| > and maybe try to keep the other managers from interfering with
| the work also.
|
| I think that's what good managers are supposed to do. As in,
| that's their entire job.
|
| Managers are not necessarily good at doing the actual work, but
| hopefully, the people they manage are. The thing is: running a
| business involves a lot more than doing the "actual work",
| coordination, dealing with customers, etc... Managers are
| supposed to shield workers from all that, so that they can
| concentrate on the "actual work".
|
| For example, a somewhat idealized but not so far from the truth
| exchange with my manager could look like:
|
| - The customers is unhappy with the latest release, he says that
| X doesn't work as expected, can you tell me why?
|
| - Uhm... X wasn't in the specs so it wasn't tested, but sure, it
| is a bug
|
| - Ok, how long you think it will it take to fix it?
|
| - Probably around two days
|
| - Ok, let's make it 4 to account for risk and management. It
| shouldn't cause major delays but I may need to find some extra
| budget, I will negotiate with the customer since it wasn't
| originally planned. In the meantime, work on fixing that bug and
| tell me how it goes.
___________________________________________________________________
(page generated 2023-07-22 23:00 UTC)