goopthink's comments

The company board’s sole job is to hire and fire the CEO when appropriate: https://reactionwheel.net/2021/11/your-boards-of-directors-i...

However, having been on a team that prepares board materials and also having presented to a company board, I can tell you that the information they receive is extremely carefully managed in a way that allows responsibility to seem to flow downwards rather than upwards. What you see as an IC or as a manager or ever director is extremely different from the cause and effects a board sees in a monthly or quarterly update. Hence they often come to different conclusions than the people in the trenches would. That said, I’m sure this is true for any large organizational unit (government, military, corporations, nonprofits, etc).

This is nice if it works, but management and leadership are specific skills that not all people have off the bat.

What is it that management does that would lend itself to transferability and rotations? If leadership’s contribution is primarily to provide updates to others or to schedule meetings, sure that’s easily replaceable. If leadership is about being empathetic and resolving conflicts, everyone brings a different style of handling this to the table and not everyone wants that sort of work. That’s the start of politics. If leadership is about making tough decisions and being held accountable for those decisions and getting teams to buy in and coordinate work around that, then switching people every six months could destroy any accountability and stability entirely.

Politics is what happens when two sides disagree, and what happens next. You aren’t going to avoid it except without groupthink. Most people are reactive to “bad” politics, just like bad sales and bad management. When it is handled well, people don’t notice it or realize it.

I don’t think this is relegated to certain industries or certain team sizes. It’s a question of roles and responsibilities, and if changing a company’s M.O. from one thing to something quite radically something else. If you’ve ever tried to change a company culture (really, a collection of a bunch of individuals’ cultures), then you know this is a huge huge task and it’s often easier/lower cost/more effective to understand your current culture and how to be most effective within that than to come in and try to change everything.

Also, Chesterton’s Fence and the like. We’ve have great social experiments in rotating leadership and in practice, people bring whatever lens they view the world to the leadership table, which is great until it isn’t.

Seriously caught off guard by this as well. It's not the fonts, it's the characters used:

- The ʀᴇмᴀιɴs of a tall male and sixteen female skeletons were identified among hundreds of gold and silver artefacts and thousands of coins.

- The women are presumed to have been wives and concubines of the leader, who were κιʟʟᴇᴅ to accompany the warlord in the afterlife. The amount of treasure and the number of sᴀcʀιғιcᴇᴅ animals and people immediately led the archaeologists to consider that the site was certainly the ʙuʀιᴇᴅ site of a really powerful Mongol warlord.

Not sure why certain "grim" words are in special characters.

Peter Reinhardt (Segment’s CEO) goes in depth about this journey (and more) in the “Learning How To Sell” episode of Patrick O’Shaughnessy’s “Invest Like the Best” podcast. Likely the original source for this post: - https://open.spotify.com/episode/61c5XhkcxEave8Cd6j55w1?si=F... - https://american-podcasts.com/podcast/invest-like-the-best/p...

But even human-generated work has all sort of domain-specific “fair use” rules to comply with, including plagiarism (academia), open source licensing (code), attribution for generative works (CC) and so on. People who make too closely generative works are scrutinized and face social and business pressures (art, law).

Today’s ML output throws everything into a mixer and then blanket-calls it ML-generated output, because the original training content has been separated from the social and legal frameworks that govern it.

"Write Useful Books" by Rob Fitzpatrick is an amazing guide for how to write, test, edit, and polish technical nonfiction.

… and in retrospect, was it worth it? Or was it a pyrrhic short term victory at a huge expense for something that would have happened eventually anyway but at a slower pace? Was this all just a quest to accelerate the inevitable outside of what overlapping Overton windows allowed for?

Best speed reading technique is actually to just skip the boring bits - the fluff that most nonfiction books include to move the narrative between ideas or to reiterate a point. Combine that with note taking and you have a very powerful reading technique. Same thing for most fiction, because a lot of words are spent on exposition and to get a character to/from a scene.

There’s certain kinds of dense nonfiction this doesn’t work for (dense because it doesn’t have filler), or literary nonfiction (that you can slowly savor for the writing or narrative).

I used to relish a choice set of words to describe an idea in a way that just makes it click for me, but I’ve found that (a) this doesn’t lose that because a well written sentence that doesn’t communicate anything of substance is actually a bad sentence (style over substance), and that most sentences (in nonfiction) are pretty bad, and that’s ok. Moreover, I’ve found that simpler writing ends up being more effective, regardless of any personal preferences for Cormac McCarthy-like prose.

Using Clubhouse as the end-all for social audio does the "space" a disservice, IMO. I used Clubhouse early on and it fell squarely into every single trope and commentary that everyone here is posting about it.

Much later, I was introduced to "Cappuccino" [1], a social audio app that couldn't be more different from Clubhouse. It's slow-social (you only get updates once day (the cappuccino composed of 'beans' that everyone submits). Each audio update is capped at 3 minutes (though you can submit as many as you'd like), and you can attach a photo if you'd like. The app auto-adds some generic intro/outtro music and production cleanup and combines it into a single podcast-like update.

I've found myself using this pretty actively with small groups of friends. The audio-first approach makes it easy to just talk about something (an idea, a life update) for a few moments (low cost to participate). The production value and once-a-day update makes it feel like a nice 'ritual' to receive everyone's updates. The intentionally asyncronousness emphasizes listening and thoughtfulness against trying to hop on to a comment thread. It honestly feels like sending postcards/letters out to folks... but audio. Can you do this as an audio group text? Kind of, yes. But that's like saying "you can recreate instagram by sending photos over whatsapp." Yes, but that misses the point.

I'm not affiliated in any way with them but I think they're a very neat counterpoint to Clubhouse in terms of "social audio" (and slow vs fast social).

[1] https://apps.apple.com/us/app/cappuccino-stay-in-touch/id150...

Animal Crossing, Stardew Valley have a lot of great game mechanics and are also about discovery, trade, and building relationships.

Factorio is probably a bit more advanced, but meets your criteria (except for story, maybe). There is a rabbit hole of games like that to go down.

Assassins Creed Origins and Odyssey have “education” modes that are about exploring the world and not murder.

The Mario-plus games (Tennis, Racing, Party) tend to be not violence oriented, are collaborative, but have super hokey stories.

Old school point and click games are definitely up there (Monkey Island, Myst) as people have mentioned.

Ico and Shadow of the Colossus do have violence and battle as central elements, but not in a COD type of way.

A challenge is that most games rely on competition and conflict as core drivers of both the story and the game mechanics. I think something like Tomb Raider could easily minimize conflict while still retaining a lot of really interesting puzzles, game mechanics, and story elements… sometimes playing that game (and uncharted) you feel like a mass murderer with the body counts you rack up. But other games like Metal Gear Solid are designed to allow you to get through them without needing to kill anyone (subdue/knock out though). It’s also hella hard to do that.

Death Stranding is an interesting one to consider as well. There is some violence and extremely dark themes, but aside from the boss battles it’s really minimal on guns and violence.

Ape Escape for PS1 kind-of fits the mold as well - capturing escaped monkeys is a really fun.

Katamari Damacy (spelling?) is really fun as well- you roll up things under your magic rolling ball becomes planet sized.

The Ace Attorney series is also almost entirely narrative and puzzle.

Mortifying, but thanks for the catch! Should be fixed now.

This is a really valuable point and we faced a lot of ground-level resistance because of this. Teams and people were incentivized to care about the wrong things. Those things made sense in the past, but the structure and incentives of the engineering org did not keep up with the changing business needs. Again: not a knock on historic decisions (which made sense at the time), but a reflect of necessary change. Changing the incentive structure was implicit in the reorg we did and it was one of the most painful parts of the process.

That said, the reorg allowed for more effective parallelization by making teams more independent, and thereby avoiding the "I'm sitting here and unable to get anything done" problem.

But yes, if people are not in consensus, you'll have sabotage. The Lippit-Knoster model for managing complex change does a great job highlighting this.

I'm not sure I agree. There's two key elements:

1. If you don't properly evaluate the work and be selective with what you work on, actual engineering time will be allocated to too many projects. People spin their wheels working on potentially insignificant things, which is a morale killer. So thinking about the business cases was a way of reducing work, not adding work.

2. I tried to emphasize that thinking about business cases is something product and engineering management/leadership need to own, not necessarily IC engineers. ICs can add ideas to the backlog and identify opportunity, and it is the job of PMs and EMs to evaluate those ideas and sequence them for being worked on, relative to other projects. The feedback loop that is important to ICs is the impact of their work in terms of user metrics and goals the project was supposed to accomplish. I don't want to get too heartfelt about it (because Capitalism, Yay!), but there's a difference between churning out features into a black hole and knowing how your deliverables affect the people for whom you build things, and letting that continue to inform your work.

OP here. I think those are good points.

Particularly: "perhaps the plan is not what ended up mattering so much as having someone who was willing and able to push it through.". This is very true. It was a combination of having tenacity to grind through a lot of politics and repetitive conversations and doubts that everyone had, while also addressing extremely real technical and process issues. Previous leaders often brought one or the other to the team: they either knew what needed to be done technically but couldn't push a plan through, or were politically savvy enough to get changes implemented but they just ended up moving deckchairs around. When I stepped in, I inherited a team that did this twice previously and everyone had zero trust and learned helplessness. I wrote this up and tried to emphasize the slowness of the process and the fact that it wasn't a "one simple trick" type approach because that was the case.

Or: "If no one will listen to you or take your advice, it's worthless." This is true. We had a few really brilliant developers cursed with a cassandra complex: they correctly identified the problems but given their way of communicating, they actually fostered resistance to the changes. Communication of the plan and building consensus is as important as the plan itself, if not moreso. Every plan will need to be adjusted based on reality and context, but as long as you build consensus and goodwill, you'll be able to have that flexibility.

With regards to your point about technical staff, we were an enterprise sales organization where decision making was concentrated in the finance and sales departments. It was extremely sales driven. The reason we were able to push this through was precisely because the company had lost faith in product and engineering to accomplish anything after a series of poor launches and chronically missed deadlines. I actually think the problem is that if engineering leadership did have more trust, they would have pushed back on this. It didn't look good to "give up and try to just do one thing at a time" as we did. For most organizations, that's painfully radical. But in the words of Munger/Buffet: "Don't just do something, sit there!"

This is very fair! We used a few guide posts:

- 1: Keep asking "why is this valuable" until you get to the money questions. It's often a few layers deep. Not being able to get at that (missing an ability to quantify) was in itself something that engineering leadership needed to work on. After all -- how can you prioritize between two things if you can't figure out what value they create?

- 2: Most engineering teams know that they might be able to save some time by refactoring. We figured out the average hourly cost of engineering effort and used that as a multiplier for time saved by a new project's implementation. You can take it a step further and subtract the cost of working on a project from the time it ultimately saves you to remove "dumb" refactors that take longer to deliver than time they save.

- 3: If you can't get to a tech debt's value, that's a red flag as to if it actually creates value. This was true for features and business requests as well. We also said no to features that "felt good" but ultimately created zero value (some redesigns included). "Rewriting something in a new language" because a new sr manager with strong preferences joined the team was a big culprit of these sorts of projects.

- 4: We also often asked if a tech debt project needed to be done independently of other work, or if it could be included as part of a new feature that we were working on. An example was that one team pitched rewriting a microservice because it had no API. On the other side of the company, we had a project to get rid of that feature entirely and replace it with a different functionality. If tech debt projects were handled entirely within the domain of engineering, we would have spent weeks rewriting something only to throw it away a month later. Hence the need for bubbling tech debt up to the single stack rank, and thus treating tech debt projects the same as any other project we were working on (with appropriate visibility, buy-in, and evaluation of value/urgency).

OP here. We had a lot of discussion about where Tech Debt falls on the spectrum of projects to work on. That merits its own post. But the gist of it is that resolving tech debt has value. The challenge is that most engineering organizations are awful at describing and communicating that value.

For example: "If we refactor this code and migrate to a new server, we'll be able to deploy in 15 minutes instead of 6 hours, and we'll be able to ship features faster to customers with lower risk. This means that we'll get back ~90h of engineering time per week (6 hours x 5 people x 3 teams), and our defect rate will go down by 50% (We see 10% of customers churn due to preventable defects).. Therefore, there is $702,000 savings in engineering efficiency (more time available) and would decrease churn by 10%, resulting in [X] more value retained."

Once our engineering team started thinking about the business case for why tech debt should be prioritized, they started to make really compelling arguments for why something needed to be worked on, and we could evaluate it against explicit business/feature requests. This value rolled up into the form of decreasing costs or increasing revenue.

Again: resolving tech debt has value, and the engineering leadership needs to work on figuring out what that value is and how it stacks up against all of the other valuable work that the company wants to do to grow. Engineering leaders who don't understand this often struggle at the executive level and ultimately fail the teams they represent.

OP here -- something I didn't touch on is that this is really common when a company transitions from early-stage to mid stage. The operations of a small company and the operations of a mid size company (and the operations of a large company) are completely different. The problems start to happen there is a mismatch between what you are and what you think you are. If you implement big-company practices for a small startup, you're often going to be overburdening the team and losing agility. When you are a med/large company but operating like a small company, you'll see chaos and inefficiency. Part of the problem is that there's no clear line. Observant engineering and product leaders tend to have an intuition for when practices need to change... I think team size and revenue/contract size (for B2B) are good heuristics. But more often than not, it's a stumble through the transition and folks feel the pain before figuring out the solution.

"The Mom Test" is an awesome look at that -- how bad questions and worse feedback leads to a lot of wasted effort. Highly recommend it. http://momtestbook.com/

That’s a comment from 2013, now 9 years ago. Since then, healthcare technology has really changed. Compliance and auditing are pretty standard with easy to follow playbooks, and there are plenty of off the shelf tools HIPAA-compliant as soon as you sign a BAA with them. If you’re in health tech, this is the floor, not a high bar.

That said, there can be a few times when your comment accurately describes what’s going on:

- a non health tech vendor needs to comply with a healthcare client’s needs and they are navigating HIPAA and HITECH for the first time.

- this is often paired with a situation where the company never refactored their SaaS software past mvp prototype phase and so they have no logging or controls and effectively need to rebuild their entire system to be security first, and healthcare regulations are just one of the factors they need to consider as they expand markets they service.

- a company is concurrently trying to get SOC and/or other certifications. Those get pretty intense.

For situations 1 and 2, that’s when a lot of vendors will explicitly say they aren’t HIPAA compliant and choose not to serve healthcare partners (vendor evaluation in healthtech is a pain in the butt because of that). For situation 3, yes, that’s a pain. My own team went through that and it was a year-long process.

That said, there is an initial upfront cost with regards to documentation. However what most people complain about are the requirements to retrain all employees semi-annually on data privacy and protection best practices, which kills a full day or two of company productivity.