The first non-bullshit book about culture I've read

To some extent, I'm no longer curious about "leadership" ideas about organisational culture.

I understand that culture counts for a lot, but modern organisational cultures are getting complaints that "leadership" is not going to solve at scale.

Maybe motivation/attitudes can be improved and a naval hierarchy can work better, but this is not the typical issue in corporate culture.

I'm curious about structural answers. A lot of culture comes down to how success and failure work. If a company culture is bad at risk-taking and internal entrepreneurship, a "culture of openness" can't fix it.

To get genuinely failure tolerant and opportunity seeking, organisations need to structure for successes and failures.

How are resources really allocated in the company? How are successes and failures really determined and what are the real ramifications.

So... (a) organisations need some formal/mechanical processes governing the pertinent decisions: resources and goals. Formal processes can be examined more honestly and biased to (or against) risk.

(b) If you really opportunity-seeking, risk taking culture... then you need "money-where-mouth-is" mechanics. It doesn't need to be fully "market-based," but someone needs to be throwing themselves behind opportunities because they think that they'll be successful.

The problem that runs through both Google (eg) and the naval ship is a culture of "do enough, and no more." The solution is usually to raise the "enough" bar somehow... motivation, discipline. That works when what you want from employ/organisations is "enough."

If you want more than enough, I think the structure needs to change.

This book explained a lot about a boss of mine. Ex-military, tried to run our department like a battalion, took pride in "battlefield repairs" of code, never let anyone think for themselves or contribute.

Only communicating through superiors...Micromanaging at its best, it was an all-out terrible way of doing things.

Adams has gone a bit nuts in recent years and has become quite a controversial figure. Like, Ive seen him in political flamewars on Twitter responding to criticism with pictures of his abs.

He was a little weird for a long time, but his divorce in 2014 kind of unmoored him.

Lord yes. It's both. It's very much both.

Small companies tend to have everyone working on the same thing. You might have a marketer, a couple engineers, etc, but they all care about the same thing.

As you grow, you silo. You have a marketing department, and an engineering department. There starts being disconnects between each group; engineers don't know what marketers are doing, marketers don't know what engineers are doing.

As you get bigger still, you silo the silos. Now you have your client dev teams, maybe a couple backend dev teams, various marketing teams, some data analysis/engineering teams, etc. To get a change through, now, you have to get disparate teams, all with different criteria for success, pulling in the same direction.

A lot of the time companies notice that better culture helps. It surely does. If I care about the other teams, even for things whose success/failure does not impact me directly, it leads to better results.

But the core problem is one of process. It's also one of the things that these companies trying to be 'agile' have clearly missed; rather than creating a 'self-organizing team' by taking one dev from the client team, one dev from each backend team, a marketer, a data guy, etc etc, and building a team out of them, that is responsible for a feature (and it can be a somewhat ephemeral team, it just needs to be one who is responsible for the success/failure of something, and can truly own it), they've instead created "self-organizing teams" inside each silo, and then are left with trying to chart a path for a feature across all of them via project managers or similar, and it's both incredibly slow, and incredibly painful.

some authors try to distinguish complexity from .. hm.. "chaotic" ? in that, complex means a lot of working parts to form an action chain (or similar) .. contrast to other systems that are not knowable or repeatable, like actual economic systems, or an enterprise of humans doing a business function, including the considerations of humans

Engineers are often taught to simplify and clarify, for great result.. but not all systems are actually decomposable that way .. some schools of business management too..

So a moving, non-trivial, not-reproducible system of systems cannot be considered 'broken' because.. there is no substitute for it to test a fix