Item — HN Reader

Mostly a great piece. The only thing I need to challenge is the default assumption that leadership is automatically correct that "legibility" is worth all the overhead. Imagine if you brain had to be consciously aware of every breath you take, every time you move a finger, etc... you'd get nothing done. Same deal if a CEO has to be aware of and approve accelerating your unit tests with parallelism or whatever.

I think the reality is that a CEO (sort of like a president) only has about 7% control over a company. The rest of it is everybody they've hired -- they are just the brain not whole the body. However they like to believe that they are the most important thing, and quickly disregard everything they don't have the time or specialty to understand (i.e. seeing engineers as interchangeable when one may be a genius who got into MIT and could be advancing whatever field he works in -- while the other is just some random bro who took a bootcamp).

When people talk about something like google succeeding it's easier to give credit to 2 founders or a CEO than it is to track the dozens of brilliant employees who built the best search/mail/maps/ads/etc platforms

1 comments

> Imagine if you brain had to be consciously aware of every breath you take, every time you move a finger, etc... you'd get nothing done. Same deal if a CEO has to be aware of and approve accelerating your unit tests with parallelism or whatever.

This is a strawman. No competent CEO thinks they need to be on top of your unit testing practices. The levels of legibility that companies actually aim for are much more defensible.

> The levels of legibility that companies actually aim for are much more defensible

Many companies run in such a way that there is no bucket for "engineers get to do stuff they know is important x% of the time." So what happens is that things that executives don't understand the significance of all get 0 time allocation. Other teams may be told they aren't allowed to work on something owned by the CI team (again often for legibility reasons).

This is how I work at a "startup" that has just a single test environment that everyone has to share after 10 years of existence.

I worked at a small startup-ish company like this: No bug tracking, no source control, no dedicated build machines (builds were published off of a random engineer's laptop, based on whatever code he had on it currently), no tests, no documentation. None of these were seen as important by the CEO (he was not a software guy). He just wanted engineers cramming features all day. When you started talking to him about development process, toolchains, infrastructure, best practices, his eyes would glaze over and ask how this helps him deal with his 5 screaming customers right now.

The CEO definitely felt he needed to be involved with these practices, to forbid them.

Did it work? Did the company fare well?

The most legible metric in the vicinity of responsible, high-quality software engineering practice is unit test coverage. It's practically guaranteed that VPs of Engineering are reporting on test coverage to the CTO, and not implausible that he's reporting on that in aggregate to the CEO.

> This is a strawman.

It is not. I once had the misfortune of glancing at the metrics that went into an "executive dashboard" for the CEO/CTO at a startup, and started paying close attention to what they talked about during the weekly all-hands. Other more recent, and widely experienced examples of micro-management by CEOs are forced RTOs and diktats forcing employees to "leverage AI" in some form or fashion, with little care about how this impacts individual teams.

> No competent CEO thinks they need to be on top of your unit testing practices.

You seem to be acknowledging that such CEOs exist, but you built an escape hatch by labeling them as not competent. Your second sentence appears to follow the first, but it doesn't, and is a an unfalsifiable tautology.