Corporate legibility for software engineers | Hacker News Reader

Corporate legibility for software engineers

matt.blwt.io

120 pointsGarethX21 comments

Great article, very true.

"For some reason, corporate legibility tools often have poor UX for those who interact with them who are not administrators."

That's because administrators decide which of these tools to use and buy. Tools then focus on pleasing them first. This reminds me of a similar situation with doctors. Some years back there was a great article in the New Yorker called Why Doctors Hate Their Computer. There is a similar dynamic where doctors waste hours on documentation that is then read by hospital administrators who then base their decisions on that. To the administrators this is great, they can see patterns and react to them. To the doctors, not so much.

In my experience (not the views of my employer) the most important stakeholder for an EHR is the ONC (federal government). Design-by-committee requirements with the happy coincidence of making it almost impossible to innovate or disrupt the industry. They change all the time, requiring a ton of dev effort just to stay in business, which favors giant companies who can afford that "rent". Next is health system administrators (whoever decides whether or not to buy, directly affecting revenue growth). Next is insurance companies. For the amount of revenue they pull in, a shocking amount of practices/hospitals/etc are so financially insecure that if the payers drag their feet for even a short period it can put them out of business. Actual healthcare providers and patients are too low on the list and it sucks.

Legibility also increases the ability for a large organization to chase singular ambitious goals.

For example: software estimation is hard. It takes time, it's highly inaccurate (frequently by 2x or more), and rewarding good estimation incentives worse software.

But having deadlines helps functions like marketing and sales immensely. Marketing can plan effective launches, and sales can guide customers towards new products with minimal lag in uptake.

Lots of corporate life is like this. It's a net good if it's used to deliver a better experience to customers. It's a constant fight to make sure legibility efforts aren't being used to hoard power for personal gain.

>It's a constant fight to make sure legibility efforts aren't being used to hoard power for personal gain.

At some point in the chain of command, it is always for personal gain. It might be the shareholder at the top, or it might be a middle manager further down the line

Eh, I find this gross.

It seems like the premise is "To succeed in bureaucratic companies you must become a bureaucrat".

But what I witness is every company that becomes beureacratic dies. And it dies to smaller companies that do more/better with a thousandth the headcount. And I see this natural selection as a good thing.

Maybe if your only goal is to be the vulture sucking money out of a terminal dinosaur these are good skills to adapt. But I think it's better to join a place that isn't lost to meaningless metrics and do work that's valuable to the customer and explain it to other humans in human ways (with a reasonable amount of measurement).

It is a fundamental opposition:

1) cooperation and altruism produces more effective companies

2) ...but machiavellianism produces more individual reward from a company

Which is why the corporate values of any McBig McOrg reflect #1 but day to day is inevitably #2 is what actually happens. Everyone is doing #2 while pretending to do #1, or couching it in terms of #1.

For techies, it is absolutely necessary for you to realize what is going on in companies, since our lot is the ones that generally want to avoid middle management machiavellianism and just concentrate on producing value.

Being able to work in a large organization to accomplish goals smaller organizations could not is one of the greatest accomplishments of mankind.

The part that is arguable is whether or not smaller organizations could accomplish the same.

I have a hypothesis that it's literally just LOC. The more lines of code, the more SWE you need to be stewards of that code, the bigger the bureaucracy.

It’s not LOC, it’s the architecture.

Seems like you both mean the same thing, complexity, a new acronym might be needed "Compound Lines Of Code (CLOC)".

I actually don't, but that's another interesting hypothesis.

My hyothesis is that all these "simple" lines of code that are 1000s and 1000s of lines of code, are actually a burden and produce bureaucracy.

> "To succeed in bureaucratic companies you must become a bureaucrat".

Yes, that is exactly the premise! "Don't hate the player, hate the game", etc.

Luckily for all of us there are multiple games we can play.

" ... as soon something is quantified, power is given to the measurer."

Maybe this is what the "agile wars" are all about. To measure the project progress you have agree on how to measure it, and then whoever defines those rules has the power.

This is half of Scrum in my experience. Hours and hours and hours of meetings arguing over the accounting rules for work with the Scrum Master eventually imposing something and using it to beat you down the road.

Power is given to the person responsible for the content of the measurement. The guy making the reports is rarely the one who wields power. The receiver of the reports is the one who gains power.

The guy telling the report-writer what belongs on the report arguably has more power than the recipient of the report.

That's one of the reasons for agile's

Working software over comprehensive documentation

Working software is the common currency, we can all understand what the software looks like when it's working. (If we can't, we have whole different set of problems to solve first).

It also avoids the problem Goodhart's law: when what we "measure" is the actual software to be delivered, it remains a good measure.

Good article. A lot of this boils down to: you want to be the author/creator/owner of as many docs as possible. Even docs that are a collaborative effort.

If you have enough business understanding and are interested in the product your company delivers, legibility tools can help you see your personal contributions in context. I think that’s pretty fun. At the least it can lend some more meaning to the daily routine.

Making work legible can be good for the workers as well! Sometimes. Often not. Jira Metrics / LoC can be used to help justify promotions and raises. Or wrongly deny them!

That point is made in the article.

> By participating in the legibility efforts, they have the opportunities to make the measures work for them. For example, ensuring that impactful work is appropriately visible to the group that can decide promotions is important.

tl;dr: In order to master the state's attempts at legibility, one must embrace the legibility and use it to advance one's own aims.

I don't think that's exactly what Scott had in mind, but sure: if you want to equalize manager-worker power imbalances in the workplace, it might be possible to work collaboratively to make legibility-creating metrics more accurate and fair.

Reply on news.ycombinator.com