docs: update page on company culture

docs/company/culture.md

@@ -7,37 +7,104 @@ outline: [2, 3]
 
 ## Values
 
+As a company, we live by 5 key values that help us do our best work.
+
+### Openness
+
+We are open to ideas. We include people of all backgrounds and cultures. We are open to experimentation and adapting as we learn. We share information freely.
+
+### Productivity
+
+We are focused on getting things done through a blend of individual effort and cooperative collaboration. We work on incremental, iterative improvements that build up over time into big accomplishments.
+
+A majority of our work is done asynchronously. Systematic parallelization helps us make the most of our time. We kindle a sense of calm urgency, prioritizing our work, doing it well, and moving quickly to what is next.
+
+### Creativity
+
+We bring creativity to everything we do. Our products, our processes, the problems we face, our plans for the future. We share creative ideas with each other, with our customers, and with the world.
+
+Not everything we create will be wonderful. Let the learnings from previous efforts fuel the next creative burst.
+
+### Kindness
+
+We use empathy to treat others with respect and honesty. We see problems from the same side, and work on them together. We help each other. We can be honest with others and ourselves. Sharing our perspectives provides a chance to see more angles of the problems we face, giving us an opportunity to find better solutions.
+
+Being nice is...*nice*, but in the extreme, sugarcoating everything masks life's true flavors. Deliver your honest message with kindness.
+
+If something is not right, assume good intentions, and seek to clarify the situation.
+
+### Long-term thinking
+
+We keep our eyes on the horizon. While we need short-term outcomes to make progress, we use long-range objectives to remember where we are heading. Iteration is one of the keys.
+
+Plant seeds that may grow later. Stay positive.
+
+Maintain integrity in sales deals, customer interactions, partnerships, investor relations. Avoid burning bridges over small matters.
+
+
+### Other qualities we value that we attain via the main set
+
+**Profitability**
+
+At some point, we need to make more money than we spend (breakeven), and then we need to make more than we are able to spend (profitability). At our current stage (pre-seed), this is not a goal.
+
+**Growth**
+
+This is a huge goal at the moment, and will be for some time to come. Growth is a side effect of being successful. How we grow matters.
+
+
+### Values are not absolutes
+
+Our values are meant to help us align on behaviors that are condusive to loving our work and getting great results. As with any set of qualities, these are not absolutes.
+
+For example, while we value openness, we are not open with people's private information. We are closed about our financial records. We use passwords and encryption to protect our internal systems from harm. There is a boundary beyond which openness is a liability. Likewise, while we value long-term thinking, we have to show incremental progress in order to attract customers and stay in business.
+
+Bigger companies often get into trouble when higher-ups start to abuse the values, using them as an excuse to mask political behavior. Remember to keep our spirit of the values, and use them as a guide for how best to work.
 
 ## Life at Koor
 
+Koor is a fully remote company with team members in separate countries and of different backgrounds. We are bound by a common interest in building great software to help the world.
 
-## Handbook
+Given our geography, most of our work is done asynchronously. Being distributed has a lot of advantages.  We have a lot of freedom to structure our days to suit our lives. We can bring the best talent the world has to offer wherever talented people have access to the Internet. We also save a lot of time we would otherwise waste commuting to and from an office.
+
+Being good at asynchronous work takes effort, and we keep thinking of ways to stay coordinated without getting bogged down in meetings.
 
-Koor is a fully remote company. That has a lot of advantages. To name one, we can bring the best talent the world has to offer wherever talented people have access to the Internet. For another, we save a lot of time we would otherwise waste commuting to and from an office.
+## Handbook
 
 A cornerstone that allows remote work to be effective is a handbook that is the single-source-of-truth for how we operate. You are reading the handbook now. If we have done a thorough and careful job, many questions are answered in these pages, saving people time in not having to repeat ourselves as new people come into the company, or we engage in a particular process for the first time, or we have to remember how to do that thing we don't do very often.
 
 If you need further convincing that maintaining and depending on a common handbook is vital to running a remote company, [read this](https://about.gitlab.com/company/culture/all-remote/handbook-first-documentation).
 
 ### What goes in the handbook
 
-The handbook is meant to include just about everything we do and how we do it. It may be easier to define what belongs here by listing what does not belong here. If something is not in the following list, perhaps the handbook is the best place for it.
+The handbook is meant to include just about everything we do and how we do it. We will use the review process to catch anything that ought to remain private.
+
+#### Exceptions
+
+It may be easier to define what belongs here by listing what does not belong here.
+
+**Technical documentation:**
+
+Some content is public and lives outside of the handbook. Code documentation and developer guides are good examples that live with their respective source repositories.
 
-**Things to put elsewhere**
+- Docs that explain how to use software (dev guide, API specs, etc.) we build should live in the software's source [repository](https://github.com/koor-tech).
+- All other technical information and knowledge sharing goes in our [Knowledge Center](https://kb.koor.tech/). 
+- Design artifacts for released software belong in the Knowledge Center or source repo. Choose one and cross link from the other.
+- Project work is tracked in Linear.
 
-- Technical documentation:
-  - Docs that explain how to use software (dev guide, API specs, etc.) we build should live in the software's source [repository](https://github.com/koor-tech).
-  - All other technical information and knowledge sharing goes in our [Knowledge Center](https://kb.koor.tech/). 
-  - Design artifacts for released software belong in the Knowledge Center or source repo. Choose one and cross link from the other.
-  - Project work is tracked in Linear.
-- Company Secrets
-  - We do have a few secrets, although the line between private and public information may be more lenient than you expect.
-  - Any related to system access - passwords, recovery keys, account numbers, and so on - should be stored in 1Password.
-  - We also have a private handbook. Ask if you think you need to see it.
-- Customer information
-  - We never want to share or leak private information about our customers, primarily for their privacy, which is reason enough.
-- Personnel information
-  - We also do not want to expose sensitive employee information. That belongs in our HR systems only.
+**Company Secrets**
+
+- We do have a few secrets, although the line between private and public information may be more lenient than you expect.
+- Any related to system access - passwords, recovery keys, account numbers, and so on - should be stored in 1Password.
+- We also have a private handbook. Ask if you think you need to see it.
+
+**Customer information**
+
+- We never want to share or leak private information about our customers, primarily for their privacy, which is reason enough.
+
+**Personnel information**
+
+- We also do not want to expose sensitive employee information. That belongs in our HR systems only.
 
 
 ### How to add content
@@ -46,14 +113,44 @@ This handbook is written primarily in markdown, which makes it easy for anyone t
 
 If you are on the less technical side of things, never mind any of that. Just write the content in a Linear issue, and buddy up with someone who can help get it into the mix.
 
+Every change to our process should start as an update to the handbook. The update should be written as if it has been adopted. The changes become a pull request (PR) in the handbook repository. That is everyone's opportunity to comment on the proposal, to point out problems, and to suggest improvements. If there is general agreement, especially by those who are directly impacted, the change is merged into the handbook and becomes *The Way*.
+
 
 ## Rituals
 
-- Watercooler - for social chatting (although work slips in from time to time).
-- Demo Time - share something with the group, something you worked on, a bit of knowledge, someone cool that you found, a problem you are having, anything goes.
-- Retrospectives - time to think about what is working and what might be improved.
+### Watercooler
 
+The water cooler is an opportunity to meet up with colleagues. Discussion topics range from social matters (e.g., How are you doing? Are you doing anything fun this weekend?) to work topics (e.g., What is your opinion about the best way to do XYZ? Do you know how to fix a problem with PQR?).
 
-## Team Stories
+We have a few water cooler sessions planted throughout a 24-hour day. Pick that ones to attend that make sense for your working hours. Since these are optional, you might want to ask people to join if you have something specific to discuss with them.
 
 
+### Demo Time
+
+Demo Time can be used for three types of topics. Any demo should be recorded at least for internal distribution. Recordings help those who are unable to attend in person, and can be replayed as a reminder or to look for specific points of interest.
+
+1. Share what you are working on. This could be completed work or work in progress. Show the features you completed, or describe a problem you would like help with.
+2. Share your knowledge. You could demonstrate some technology you have used, a coding practice, an approach to testing, anything that might be interesting for others to learn about.
+3. Some demos are worth sharing with the world. We tend to post recordings to our YouTube channel.
+
+
+### Retrospectives
+
+Time to reflect on recent history in order to find ways to improve. Reflection prevents small issues from become real problems. Tiny, incremental improvements will compound.
+
+The best approach for a retrospective is to give the team a place to brainstorm ideas (Google Doc or JamBoard) and at least 24 hours of notice. Then during the retrospective meeting, discuss the items that have been added, and add any new ideas that come from the discussion. The categories are meant to stimulate thinking.
+
+* Good / What is working
+* Bad / What is not working / What could be better
+* Ugly / Recent disasters
+* Action items
+
+As the last part of the discussion, decide what action items to try, usually a subset of the full list. Focus on what is do-able and seems like high value add.
+
+### Weekly Planning
+
+Review active and ready issues, and update statuses to clear what has been done and choose focal areas for the next week and cycle. Review short-term and long-term objectives to keep the team aligned on priorities.
+
+## Team Stories
+
+This is a suggestion. We can consider what this might mean for us. Perhaps Demo Time is our way to generate team stories. Perhaps we could use some anecdotes for our recruiting pages.