This reminds me of Alan work culture [1], Alan is a startup with a zero meeting policy and a very strong culture of writing. They check the quality of one's writing during their interview process.

Alan leaders also have other strong ethos like "no managers" and "complete transparency".

I really wonder if these companies are exceptions or if this organisationel model could be replicated more widely. I guess it caters to some very specific personality types.

[1] https://blog.alan.com/bien-etre-au-travail/who-we-are-and-ho...

Our work culture's obsession with meetings, which is dwindling, it seems, is due in large part to our desire to perform as part of 'productivity theater.' this has mostly been driven up by wfh. but it's interesting to me that so many people focus on performativity vs. output

I've also seen a lot of benefit of grouping recurring meetings all in the same time slot daily. I.e. all team rituals from 10-11 am daily.

Is there a way to stop scrolling hijacking on the sites like this one?

i personally can't retain any information in meetings, and i've honestly watched meeting recordings back to take notes on important info that i totally glazed over at the time. this wastes a total ~121 minutes on average, based on their estimate of time it takes to refocus after meetings.

My current employer was sold to me as a "high documentation" place. What it means in practice is that if you're trying to do something there are 5 outdated documents describing the decision making process for how the project was run, and no documents about how to actually use the resulting software. Occasionally if you ask how to actually do a task in Slack someone will yell at you that you should have searched for a specific, obscurely named document in Google Drive, Confluence, or Github. We've tried a bunch of search tools which successfully surface the million product documents, design documents, PM reports, planning docs, retro docs and standup and oncall notes related to any feature, none of which are up to date.

Sounds like this works great for them, and an awesome environment to be a part of.

However I'd be very curious to see how this evolves as the company grows. Personally, I am skeptical that this is sustainable in the long term. In my experience, most people are a) bad at writing and b) hate reading. And as a company grows, and the number of documents that need to be written and read explodes, this work pattern eventually becomes untenable. More and more meetings get scheduled to cover topics that are not well documented, which causes people to have less time/inclination to create or consume high quality documents, and it becomes a feedback loop.

(Edited to make it clear that I am not against the idea, just curious to see how it evolves)

High-Documentation is so out of fashion, for all the wrong reasons. If you are designing anything that is intended to last longer than 6 months, documentation is a critical part of the system.

Meetings are great for communicating with people here and now, but only writing can communicate with people from the future. When you meet with your current colleagues, spare a thought for your future colleagues who haven’t yet joined, and do them a favor by writing things down.

Ability to use written communication is a major differentiator between junior and senior engineer.

All developers should spend time working in support. That time will make them appreciate the incredible power and utility that documentation provides to everyone...including your future self.

In order for this to work, you also need a high-reading work culture, which is distinct from a high-writing (documentation) work culture.

I wish more people adopted Andy Grove's thoughts on meetings.

https://jondouglas.dev/lets-not-meet/

This company seems to "get it" though. We ought to protect our attention more often.

I'd take documentation over no documentation any day. Even if it's 4 years old and was last updated by a person who left for a competitor.

My personal policy was "No regularly-scheduled meetings" (which included things like daily standups).

But I worked for a Japanese corporation, so we had regularly-scheduled meetings. I was able to reduce them, though.

I was watching a DistroTube video where he was ranking multiple windows managers, and he explicitly refused to give i3wm points for having great documentation because "it's the bare minimum". Except all the other ones had crap documentation.

One can only dream everything had documentation as great as i3wm's as a bare minimum.

At my company we make all meetings optional, this really helps create the right incentives both for hosts and attendees. As a result we have very few meetings, but the ones we have work well. https://www.synura.com/handbook/general/meetings/#all-non-11...

I'm convinced that documentation, even for large companies, should just be an Obsidian vault of markdown files maintained via git which is just rendered on the web either using a simple static site generator or using Obsidian Publish. When I brought this up at my last company it got dismissed as being 'too technical'.

I know git can be tricky but it cannot be that difficult to teach people from non technical departments add, commit and push and then show maybe one person from each department how to solve conflicts. Alternatively, build non technical people a web interface for editing and committing but allow the devs to just use git as standard. Or there's Obsidian's built in sync but I don't know enough about it to know if it scales well in large organisations.

What absolutely is definitely not the solution is Confluence. I have not met anyone who has a positive thing to say about it. The only reason it is being so widely used is because it satisfies whoever is in charge of the finances because it comes bundled with Bitbucket and Jira.

If you have a high-documentation culture, you must have documentation enforcer roles. It's crazy to think you would have a library without librarians to run it.

There must be people who spend time on each team in sequence trying to follow or review their docs and get X running "like the docs say"

This group of enforcers will contain a variety of people from tech, legal, customer service, and other backgrounds who can spot trash (in their area of expertise) when they see it.

Many in this thread seem to conflate documentation with code documentation, while I use it as a means to communicate requirements to the developers. Some mockups here, some data description there, it makes all the difference. Our stories/tickets increasingly consist of only a title, a wiki link and some acceptance criterions. Works great for me as a PO, devs like it and provides a lot more context than fragmented tickets do.

I think this approach has many benefits. The main problem with most collaborations in which documents are used to replace conversation is that without a disciplined framework for structuring documents it's very easy to get lost in them.

-documents go out of date, people are usually up to the minute

-documents don't allow you to ask questions people do

-documents never forget, people do (not forgetting seems like a good thing but try working through a 5-10 year old team wiki or OneNote and you'll see why it can be good)

is this the anti-agile manifesto? Personally, I think they got it right the first time (https://agilemanifesto.org/), even if most modern agile application feels pretty anti-agile today

I thought high-documentation would be related to literate programming. Joke's on me, looks like we're going to try to reinvent LP forever.

From the outside, Gitlab seems to have solved this with a medium-sized org with all remote, and it sounds like a dream remote workplace.

Async communication, full transparency, 90-day retention in slack which forces decisions into documentation if it's important, issues/threads for discussions, and handbook for SOPs [1]

Anyone have experience with this directly that can speak to if this works in practice?

Or is Gitlab just really good at marketing their methodology as a tool to sell more subscriptions?

1 - https://about.gitlab.com/company/culture/all-remote/handbook...

I like this a lot in principle but would add two notes about doing this in practice:

1. Promote self-documentation as much as possible—e.g. meeting notes typed straight into Google Doc, discussions typed straight into Slack, issues typed straight into GitHub, comments typed straight into code—so you’re documenting as you go in a way that’s automatically archived and searchable for future reference. There are times when separate out-of-band documentation is appropriate, but that takes extra effort and can get out-of-date more easily.

2. Promote an it’s still okay to ask culture in parallel with the high-documentation culture. Asking questions in Slack can be a shortcut to finding the right document or finding out something is yet undocumented, and should be encouraged especially if the asker has already done a quick search without locating the needed information.

are your engineers evaluated on the quality and up-to-date-ness of the docs they produced? and are they paid more and promoted faster if they do produce quality docs?

if not, i don't believe you.

I thought this was a well written article and I loved the graphics (especially the one about 30 minute meetings actually taking 68 minutes). However, it's worth noting that this company is fairly small (48 members according to their About page) and that the group has been together for quite some time.

I'm not sure how well this would scale past the Dunbar number, or for organizations growing rapidly.

Either way, I'm glad they published this.

Moving to America from France, one of my biggest surprises was how poor the average engineer (person really, but engineers affect me directly at work) is at summarizing concepts clearly.

I learned a little later that "summary" exercises are not a thing taught in school here, which surprised me. In France, "le résumé" is an exercise that they constantly drill into students (particularly technical ones), in which you take a 3 page paper and condense it into 100 words. I really hated doing it back in the day, but as an adult I now am very grateful I did and wished other countries made this more prevalent.

I love companies that can actually thrive with this way of working but it only works at a certain size. This only works in a senior heavy, relatively flat engineering org. Once process ramps up due to new compliance demands or HR wants more of a mixed skill level in engineering, rapid fire product delivery and async culture dies out. I think this could be sustained in a software company in the right context, but orgs eyeing unicorn valuations or headline exits only leverage this way of working until they need to recalibrate.

Here is my summary of the content of this piece: "We only hire introverts who like working in introvert ways. But we like to pretend that we are just normal people who have stumbled on a better way of working that has mysteriously eluded all the other smart people in the world."

From my experience effective written communication and good comprehension are rare skills. That's the reason meeting culture is so resilient.

Low trust, poor communication = low documentation, high meeting.

I work as a consultant with a lot of outsourced teams who poorly communicate or seem to avoid written responsibility.

really like that thought: "low-meeting culture allows us time to do high-value tasks"

Is there any way to achieve this within Microsoft's suite?

Sadly we adopted Microsoft O365, SharePoint, Teams. How can you organize the org effectively is beyond me, how does MS do it? Are they actually using their own tools they sell others?

In our org, some departments/teams/sites have just a SP, Others have a teamspace with separate SP/document store.

Worse, any meaningful file structure/hierarchy you come up with gets sabotaged when new channels are created as they automatically introduce new folders. You cannot bind a teams channel to a separate folder in a SharePoint. Also, We have private project teams springing up and large fragmentation of information. If you do not know that a certain project space was set up you cannot find or join it.

Going with a "single Teamspace" for the whole org doesn't work either without being able to have nested channels/groups. The org is too large and complex.

I'd love to have a gitlab style handbook to be used in our org to organize knowledge and information, but I do not know if and how it could be set up technically.

> We deliberately encourage people to create documents rather than build slide decks. Slide decks can mask poorly-written content with decorative font, sleek formatting, and compelling images.

>In a document, the content is all you have. It forces people to focus on communicating their ideas as clearly as possible.

If anyone who works there is reading this: There must be a spectrum of documentation-generating talent on staff. Have you ever had to read through the product of someone who isn't very good at writing it? How do you cope with mediocrity in that skill? (Is it sometimes cause to let someone go?)