Hacker News Reader

Comment by wenc | Hacker News Reader

Management techniques come and go, but at the core of management is an understanding of systems/process and of human behavior. A really good book on management is Andy Grove's "High Output Management" [1], which to me strikes a good balance. It's a fairly popular book in SV and probably a known quantity to most HN readers. It's also notable in that it wasn't written by some management guru or business prof who's never managed anyone in their lives (i.e. Drucker), but instead drawn from the experiences of a CEO of a significant company (Intel). The blue-collar equivalent is Plain Talk by F. Ken Iverson, former CEO of NuCor Steel. [2] (not the author of APL -- that's Ken E. Iverson :)

[1] TLDR https://medium.com/@iantien/top-takeaways-from-andy-grove-s-...

[2] https://www.goodreads.com/book/show/1450374.Plain_Talk

View on HN

"What gets measured gets improved". Which really means, "what doesn't get measured, will be traded off for what does".

More importantly make sure you are measuring what really matters and not a proxy. I shut down our code coverage builds some years ago when I realized management was using that as a measure - the potential negatives from measuring that is far worse than any possible gain from an engineering improving anything. The measure is still useful, but until I can be convinced it won't be abused I won't measure it.

They were using it as a measure of what exactly? I'm having a hard time seeing how it can be interpreted in a way that's a net negative.

I've seen teams trying to get bonus points for patching thousands of files with errors. All this was done instead of innovating or writing a better module in a more succinct language that tackles the problem directly. I'd rather see employees finding ways to make sure those errors and infractions can't happen - often requiring different programming languages and tools - instead of just patching the code.

What happens when a team's code coverage drops below the mandated minimum? How do different teams' coverage numbers affect their value ranking against other teams? What's going to stop teams from gaming the number with techniques like https://www.pavelslepenkov.info/?p=110 ?

Lots of net-negative consequences can occur when management decides to measure things. Lots of net-positive too, otherwise they wouldn't ever do it, but developer productivity proxies are notoriously hard, I'd question any manager trying to make one with whether they've ever done or read about Deming's red bead experiment (http://maaw.info/DemingsRedbeads.htm)

That red bead experiment is an interesting illustration, thanks for sharing.

They wanted a measure of quality. We are an embedded system where we sometimes have to pay a tech to go our and update customer devices. Last time we had to do this the recall cost us something like 10 million dollars - that is just the price we paid the techs to drive to the customer and do the update, and doesn't count the engineering costs to create the fix. As such not having a recall event is important. (We do have customer installable updates, but for "reasons" some code cannot be updated by customers)

The negative is some people don't believe in through tests. They write a few unit tests for things they know are tricky. Then when their code coverage is low they get their coverage up by writing "tests" that take all the branches, but never actually assert anything. They know all the tricks to sneaking these bad tests in and the result is the metrics look good while hiding the fact that code is not covered.

Interesting. Sounds like tests were really needed in this case, but some people didn't want to write them. And the code coverage tools were just gamed. ie, an additional level of oversight would be needed there if you really wanted to ensure good test coverage.

I don't see how code coverage is making the situation worse though, it seems like it just wasn't enough in this case. I guess in that it resulted in useless tests by some people, it's a minor setback, but surely it encouraged others to write more proper tests.

Code coverage wasn't making it better. As one of the developers on the project, I already knew who was writing good code or not (but I couldn't do anything about it).

More generally: What gets watched gets seen. What gets seen gets attention. What's gets attention receives action.

OKRs has its roots in Groves ideas. John Doerr who wrote Measure What Matters learned about OKRs working for Intel under Grove.

Good point.

The root cause of the problem is believing that some technique can be successfully applied to all people in all departments in all companies at all times.

This seems to be a very common theme in these type of books and the people who praise them.

Well, good management books do serve a purpose: they provide you templates/mental models to reason critically from. Like anything else, you have to sift through the chaff and translate/apply to your own circumstances, but they can provide incredible leverage.

Most new managers have no idea what has been done before so they make all kinds of expensive and unnecessary mistakes. Having mentors in senior management can help moderate this, but that is assuming the mentors are themselves knowledgeable, which often isn't the case, especially at large corporations with many layers of management.

This is where understanding the management literature really helps. Reading any great book (e.g. Shakespeare) is like spending a few hours picking the brains of an incredible mind that you would otherwise have no direct access to.

Some years ago, I was at a company in a provincial part of the country where good management practices weren't widely known. There was a lack of intellectual curiosity about management within the company, so I had to look elsewhere. Books helped me gain leverage over managers who have managed for years but never thought to look outside their enclaves. I had the opportunity to try things out and refine in a small-scale setting. I've moved on since, but the knowledge I acquired during those wilderness years continues to be useful and practical in much larger scale setting.

I don't disagree that they are useful, just that they must be carefully considered and applied in situations where appropriate — not treated as a law that applies to everybody, all the time.

The same thing is true for diets, exercise, self help, etc. Turns out humans are pretty complicated and there is almost never a single solution that works for everyone, all the time.

> It's also notable in that it wasn't written by some management guru or business prof who's never managed anyone in their lives (i.e. Drucker)[...]

From the excerpted chapter of Doerr's book:

> Strictly speaking, however, his “objectives and key results” did not spring from the void. The process had a precursor. In finding his way, Grove had followed the trail of a legendary, Vienna-born gadfly, the first great “modern” business management thinker: Peter Drucker.

I've learned that one can recommend a book or guide without agreeing with everything in it, and Peter Drucker's MBO concepts (insofar as OKR adheres to them) are one of those things I don't agree with. Grove's book also has some clarifications about how OKR is balanced against long-term objectives, which lessens its ill-effects somewhat.

I agree with much of the rest of the book though.

That Grove book is on my TODO list. Thanks for the reminder. As real leadership / management books go, I thought Creativity Inc by Ed Catmull was both interesting and entertaining.

https://www.amazon.com/Creativity-Inc-Overcoming-Unseen-Insp...

Reply on news.ycombinator.com