Thoughts on "Operations" by Andrew Bosworth

Andrew Bosworth recently wrote an interesting article about structure and process, and how those are important to high functioning organizations. It really resonates with me, I've seen first hand a lot of the repercussions of not taking process seriously enough, albeit on a much smaller level than he has. Anyway, I had a few questions, and a few additions, so I thought I'd throw it out into the void.

There is a pernicious belief in our society that having a good idea is the hardest part of meaningful innovation.

I completely agree. Ideas are cheap, execution is difficult and meaningful. That said, I'm not sure that there's a "pernicious belief" in our society. Maybe I'm just naive, but I wouldn't have thought this was a controversial stance. I also wonder if this is more prevalent in Silicon Valley, where people will throw absurd amounts of money at ideas and don't even necessarily expect them to pan out.

Teams are blocked until they can get questions answered and conflicts resolved. Reviews are our primary tool for solving these logjams at Meta.

This rings very true for me. I can't even begin to count the number of times when multiple people from multiple departments are all waiting on each other to get something resolved, hoping someone else will make a decision and get things moving again. It just doesn't work unless someone takes initiative, and I never had a great idea of how to do that. I like the idea of review, although I think Boz (if I may be so bold) is using that term a little differently than I'm used to. To briefly stray, he mentions something really important in his article "On Reviews":

The final thing to know about reviews is that they are binding. If you get feedback in a review you don’t necessarily have to implement it but you must address it. Ignoring what you hear in a review isn’t an option.

This is such an important organizational agreement to enforce. Otherwise, people will just continue spinning their wheels thinking that the blocker isn't resolved yet, or that no meaningful action has been taken. I'll touch on culture a little later, but I'm not sure how to enforce an agreement like that, and I suspect it may be most effective to do that from the top down.

Teams of any meaningful scale of cross functional collaboration potentially face exponential overhead trying to align and make progress if they don’t have sufficient mutual knowledge. Even if you could establish global context at a point in time, information entropy sets in almost immediately.

Once again, I love it. I believe this explains why M&A activity is so massively disruptive to employees. "Information entropy" happens so quickly, it's hard to fight it fast enough to make positive ground when everybody's busy working on their own legacy codebases. Not to mention, there's often tension between employees, and that so that entropy is much more dangerous if folks are resistant to establishing mutual knowledge in the first place.

Noise from miscommunication and overhead can overwhelm signal surprisingly quickly so it’s your responsibility to evaluate how your system contributes to and helps people process noise.

I was working in tandem with a few teams in India on an important project at my last job, and I just couldn't seem to escape this. Our days only overlapped by a few hours, and even those few hours were uncomfortably early or late for everyone involved. My team and I invested several weeks into a project, with input from my manager and director, only to eventually find out that a team in India was working on the exact same thing. With a language, cultural, and time gap, I'm not totally sure that can really be overcome. This goes back to the discussion on reviews as well. We didn't have an organizational agreement that reviews were binding, and that was just made all the more frustrating when there's a 12 hour gap around every single miscommunication and every single pushback against some review.

Each program should have a very comprehensive set of groups covering a range of audiences: a global group open to anyone interested in a project, a cross functional group including the entire breadth of people working on it (could be open or closed depending on the level of confidential information being shared), a closed team group dedicated to each discipline, and closed working groups for any ad hoc issues that come up.

It seems like this is kind of how people naturally organize in the first place (or, I could just be misunderstanding the term "group" because I've never used workplace). But I don't think it's at all unusually for someone to either give a brown bag lunch talk or record a video going over the high level view of what their team has ben working on, and the more detailed you get, the fewer the number of interested parties you'll have around. Or, another example, someone will write up an article on Confluence about some big new widget they're building for consumption by the whole organization, and maybe some stakeholders in a business role will attend comment on Jira tickets or will be in Slack channels, but when you get down to daily stand-ups - it's just the team responsible for building the widget talking about the issues they're running into.

Finally, stable documents people can refer back to are valuable as reference points and for onboarding new people. Things like roadmaps, OKRs, as well as mission and vision statements should be pinned or posted and easily accessible. The process of generating these artifacts is another important one that should be done on an infrequent basis but at greater depth to allow people to ask more profound questions that may not present themselves day to day.

In theory, I totally agree, but I'm very curious about how Meta makes sure these things don't just get redone over and over, or just lost in the wind. Maybe Boz is thinking of higher level artifacts than I am, but it can be difficult to try to create these artifacts around operations when it seems like they're never consumed or referenced by anyone. Not by any ill intent on anyone's part, but wikis or Slack channels get crowded and increasingly disorganized with use. These things just get lost, just like documentation, and I'm still trying to figure out a good solution to that.

Being blocked needs to be seen as a worse outcome than being wrong; it is the most useless of all failure modes.

I hadn't thought about this before, but I completely agree. How employees look at being blocked is generally a great indication of the overall company culture.

We can shape culture through what we choose to celebrate and what we publicly discourage.

I think it's important to mention here that culture is just as much shaped by what we don't choose to celebrate, and what we don't choose to publicly encourage. It's very easy to get worn down when it seems like the person loudly asking questions at all hands every week is getting promoted, while the person managing to balance ad hoc requests from colleagues and their assigned work just get ignored. Speaking of pernicious beliefs, I think engineers in general put way too much importance on being the loud, opinionated one. Calling something a bad idea is a way to raise your status in the engineering world. But now I'm way offtopic.

Anyway, overall, I really enjoyed this article. I think having this kind of an operational mindset is vastly underrated around engineers, and the vast majority of organizational issues I've seen have come from someone not having that kind of a mindset. Anyway, thanks for the good read, Boz!