Recently I've only worked for companies with limited (1 max) meetings for ICs a week, I definitely recommend it.
High-documentation, low-meeting work culture
21–30 of 524 posts
Re: High-documentation, low-meeting work culture
#22"High-documentation" isn't the cure, either. Just write quality software with well-defined interfaces, minimal dependencies and smooth building processes. I want to be able to build the thing without frustration, to start playing with it in order to learn its internals and debug it. Only then can I be comfortable enough to start implementing features and changes.
"Just write quality software"
That's quite a load-bearing "just" there.
Re: High-documentation, low-meeting work culture
#23Sounds 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 eventua…
It works if you hire for people who are good at communicating and reward documentation writing in performance reviews
hiring is probably the main thing. giving some kind of documentation exercise to all prospective devs seems to alleviate concerns about communication
Re: High-documentation, low-meeting work culture
#24My 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…
> 5 outdated documents describing the decision making process
Would that place be the U.S. Department of Defense by chance?
Re: High-documentation, low-meeting work culture
#25Recently I've only worked for companies with limited (1 max) meetings for ICs a week, I definitely recommend it.
Is the lack of "meetings" offset by pair-coding, dragging out synchronous conversations in Slack, or otherwise controlling engineering time and schedule?
Re: High-documentation, low-meeting work culture
#26In order for this to work, you also need a high-reading work culture, which is distinct from a high-writing (documentation) work culture.
Re: High-documentation, low-meeting work culture
#27Sounds 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 eventua…
doesn't Amazon have a similar structure, tho? i don't know what it's actually like to work there (anyone who does feel free to chime in) but i've interviewed and from what I can tell they put a heavy emphasis on documentation. it's tough to find a bigger and more siloed company than Amazon, and it seems to work for them.
Amazon is high documentation, high meetings culture. The documentation is reviewed by peers, bar raisers, and leaders in a process called document read before being official.
Edit: Someone asked for more detail on high meeting culture. There are constant meetings between cross-functional teams, various leadership stakeholders, and ongoing operational planning. That is not including your day to day meetings within your sub team or the follow up meetings from doc reads or the new team launch meetings, etc. Amazon tech is a high meeting culture.
Re: High-documentation, low-meeting work culture
#28My 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…
Do we work for the same company? :P
Confluence has been the bane of my attempts in finding any relevant docs. Which one is the source of truth? Which one was a draft written by an overly eager to make a first impression, new employee (who is no longer with the company)? Don't even get me started on saving meeting notes to confluence.
These days, I maintain my own knowledge base on Obsidian. If there's ever any confusion or request for more information within the company, I copy-pasta the relevant note from my obsidian bank to whomever person or whichever confluence page they deem the source of truth.
Re: High-documentation, low-meeting work culture
#29Earlier quoted context omitted.
It works if you hire for people who are good at communicating and reward documentation writing in performance reviews
hiring is probably the main thing. giving some kind of documentation exercise to all prospective devs seems to alleviate concerns about communication
Agree that hiring is sure important, but I think as long as hiring is competitive, and most candidates are bad at writing, then compromises are almost inevitable?
Re: High-documentation, low-meeting work culture
#30My 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…
I would suggest introducing two things.
First, introduce The Diataxis framework ( https://diataxis.fr/ ) for documentation. It makes people think about documentation in a more structured way, and allows you to be more specific in the types of missing documentation. (High documentation cultures are often good with explanation but not tutorials, for example.)
Second, I would introduct the idea of a Documentation Portfolio. I have a review of Agile Documentation at https://www.ebiester.com/documentation/2020/06/02/agile-docu... and it speaks to another structure for how to build the documentation in a more reliable form and thinking more carefully about your audience for a particular type of documentation.