Update why-this-way.md (#9023)

* Update why-this-way.md

These edits address items 6 and 9 from the handbook notes doc: https://docs.google.com/document/d/17BhgTqCI5255RY71m5ri3nDx71DqmfYwyJmRe_nJ4Ns/edit?usp=sharing.

The content for Why open source? identifies benefits and addresses security concerns. I ended this section with a sort of call to action. This differs from other content in Why this way, but it seemed like a good opportunity. If this feels too aggressive, I can cut the Results section. 

I've consolidated the bullets for every company values, as well as wrote summaries for the values that didn't have them. The goal is to make each value more distinct and easier to understand.

* Update README.md

* Update README.md

handbook/company/README.md

@@ -26,7 +26,7 @@ While [GitLab's handbook](https://about.gitlab.com/handbook/) inspires this hand
 Fleet Device Management Inc. is an all-remote company with team members spread across four continents and eight time zones.  The broader team of contributors [worldwide](https://github.com/fleetdm/fleet/graphs/contributors) submits patches, bug reports, troubleshooting tips, improvements, and real-world insights to Fleet's open source code base, documentation, website, and company handbook.
 
 ### Open source
-The majority of the code, documentation, and content we [create](https://twitter.com/mikermcneil/status/1476799587423772674) at Fleet is public and source-available. We strive to be open and transparent in the way we run the business, as much as confidentiality agreements (and time) allow. We perform better with an audience, and our audience performs better with us.
+The majority of the code, documentation, and content we [create](https://twitter.com/mikermcneil/status/1476799587423772674) at Fleet is public and source-available. We strive to be open and transparent in the way we run the business, as much as confidentiality agreements (and time) allow. We perform better with an audience, and our audience performs better with us. Learn more about [why we use open source](https://fleetdm.com/handbook/company/why-this-way#why-open-source).
 
 
 ## 🌈 Values
@@ -44,154 +44,42 @@ When a new team member joins Fleet, they adopt the values, from day one.  This w
 ### 🔴 Empathy
 Empathy leads to better understanding, better communication, and better decisions.  Try to understand what people may be going through, so you can help make it better.
 
-- Think and make customer-first choices.
-- Consider your counterpart.
-  - For example: keep in mind customers, contributors, colleagues, the other person in your Zoom meeting, the other folks in a Slack channel, the people who use software and APIs you build, and the people following the processes you design.
-  - Ask questions in a way you would want to be asked.
-  - Assume others have positive intent.
-  - Be kind.
-  - Quickly review pending changes when your review is requested. <!-- TODO: (when you are requested as a reviewer in GitHub, respond quickly.  If pull requests start to stack up, merge conflicts can arise, or the original author can forget, or lose context for why they were making the change.  The more pending changes there are, the harder it is to sort through what needs to be reviewed next.) -->
-  - Be punctual.
-  - End meetings on time.
-- Role play as a user.
-  - Don't be afraid to rely on your imagination to understand. <!-- TODO: (When making changes, put yourself in the mindset of the end user. Keep in mind how someone might use the product or process you're building for the first time, or how someone accustomed to the old way might react to a new change.) -->
-  - Developers are users too (REST API, fleetctl, docs).
-  - Contributor experience matters (but product quality and commitments come first).
-  - Bugs cause frustrating experiences and alienate users.
-  - Create patches with care (upgrading to new releases of Fleet can be time-consuming for users running self-managed deployments). <!-- TODO: (patch releases are important for improving security, quality, and stability. Cut a patch release if there is a security concern, previously stable features are unusable, or if a new feature advertised in the current release is unusable.  But remember that people have to actually install these updates!) -->
-  - Confusing error messages make people feel helpless and can fill them with despair.
-  - Error messages deserve to be good (spending time on them is worth it).
-  - UI help text and labels deserve to be good (it's worth it to spend time on them).
-- Invest in hospitality.
-  - "Be a helper."   -Mr. Rogers
-  - Think and say [positive things](https://www.theatlantic.com/family/archive/2018/06/mr-rogers-neighborhood-talking-to-kids/562352/).
-  - Use the `#thanks` channel to show genuine gratitude for other team members' actions.
-  - Talking with users and contributors is time well spent.
-  - Embrace the excitement of others (it's contagious).
-  - Make small talk at the beginning of meetings.
-  - Be generous (go above and beyond; for example, the majority of the features Fleet releases [will always be free](https://fleetdm.com/pricing))
-  - Apply customer service principles to all users, even if they never buy Fleet.
-  - Treat everyone as our guests.
-
+- **Be considerate.** Keep the needs of customers, contributors, and colleagues in mind. Treat others the way you’d like to be treated.
+- **Be curious.** Ask questions. Try seeing situations from different perspectives. Use your imagination to find understanding.
+- **Remember the user.** Prioritize product quality. Create patches with care. Fix bugs quickly. Take time writing error messages.
+- **Invest in hospitality.** Apply customer service principles to all users. Be generous with your time. Think and say [positive things](https://www.theatlantic.com/family/archive/2018/06/mr-rogers-neighborhood-talking-to-kids/562352/).
 
 ### 🟠 Ownership
+Achieving ambitious goals requires reliability and initiative. That’s why we encourage every Fleetie to think like an owner. Your impact goes beyond the responsibilities of your role.
 
-<!-- TODO: short preamble -->
-
-- Take responsibility.
-  - Think like an owner.
-  - Follow through on commitments (actions match your words).
-  - Own up to mistakes.
-  - Understand why it matters (the goals of the work you are doing).
-  - Consider the business impact (fast forward 12 months, consider the total cost of ownership over the eternity of maintenance).
-  - Often, you'll need to own processes that won't scale. Not everything should be automated from the start. Your experience with doing things manually will teach us how to scale effectively later. 
-- Be responsive.
-  - Respond quickly, even if you can't take further action at that exact moment.
-  - When you disagree, give your feedback; then agree and commit, or disagree and commit anyway.
-  - Favor short calls over long asynchronous back and forth discussions in Slack.
-  - Procrastination is a symptom of not knowing what to do next (if you find yourself avoiding reading or responding to a message, schedule a Zoom call with the people you need to figure it out).
-- We win or lose together.
-  - Think about the big picture beyond your individual team's goals.
-  - Success equals creating value for customers.
-  - You're not alone in this (There's a great community of people able and happy to help).
-  - Don't be afraid to spend time helping users, customers, and contributors (including colleagues on other teams).
-  - Be proactive (ask other contributors how you can help, regardless of who is assigned to what
-  - Finish completely before moving to something new (help unblock team members and other contributors to deliver value). 
-  <!-- (collaborate; help teammates see tasks through to completion) -->
-- Take pride in your work.
-  - Be efficient (your time is valuable, your work matters, and your focus is a finite resource).
-  - You don't need permission to be thoughtful.
-  - Reread anything you write for users. <!-- TODO: (Check everything that a user might read for clarity, spelling errors, and to make sure that it provides value.) -->
-  - Take your ideas seriously (great ideas come from everyone; write them out and see if they have merit).
-  - Think for yourself (from first principles).
-  - Use reason (believe in your brain's capacity to evaluate a solution or idea, regardless of its popularity).
-  - You are on a hero's journey (motivate yourself intrinsically with self-talk; even boring tasks are more motivating, fun, and effective when you care).
-
+- **Be accountable.** Follow through on commitments. Own up to mistakes. Understand how your work furthers Fleet’s goals.
+- **Be responsive.** Respond quickly whether or not you can take immediate action. Offer feedback freely (even if you disagree).
+- **Think bigger.** Remember the big picture beyond your team's goals. Consider how Fleet creates value for customers.
+- **Take initiative.** You don't need permission to be thoughtful. Think for yourself (from first principles). Great ideas come from everyone.
 
 ### 🟢 Results
 We work to get results. How we work determines the results we deliver. Between overthinking and rushing, there's a [golden mean](https://en.wikipedia.org/wiki/Golden_mean_%28philosophy%29). We balance speed and sustainability to build high-quality products.
 
-- [Iterate](https://youtu.be/BW6TWwNZzIQ) your work.
-  - Look for ways to make frequent, small changes.  Small changes provide faster feedback.  They are easier to reason about when debugging.
-  - Pick low-hanging fruit (deliver value quickly where you can).
-  - Think ahead, then make the right decision for now.
-  - Look before you leap (when facing a non-trivial problem, get perspective before diving in; there may be a simpler solution). <!-- TODO: When facing a (non-trivial) problem, take a step back before diving into fixing it - put the problem back in context, think about the actual goal and not just the issue itself, sometimes the obvious solution misses the end goal, sometimes a simpler solution will emerge, or it may just confirm that the fix is the right one and you can go ahead with better confidence -->
-- Move quickly.
-  - "Everything is in draft."
-  - Think fast (balance thoughtfulness and planning with moving quickly).
-  - Aim to deliver results daily.
-  - Move faster than 90% of the humans you know.
-  - Resist gold-plating and avoid [bike-shedding](https://en.wikipedia.org/wiki/Law_of_triviality).
-- Remember, less is more.  Focus.
-  - Focus on fewer tasks at one time.  <!-- TODO: (By focusing on fewer tasks at once, we are able to get more done, and to a higher standard, while feeling more positive about our work in the process.) -->
-  - Go with "boring solutions."
-  - Finish what you start, or at least throw it away loudly in case someone else wants it.
-  - Keep it simple (prioritize simplicity; people crave mental space in design, collaboration, and most areas of life). <!-- reduce cognitive load -->
-  - Use fewer words (lots of text equals lots of work).
-  - As time allows  ("I would have written a shorter letter, but I did not have the time." -Blaise Pascal).
-- Make time for self-care.
-  - This helps you bring your best self when communicating with others, making decisions, etc.
-  - Consider taking a break or going for a walk.
-  - Take time off (it is better to have 100% focus for 80% of the time than it is to have 80% focus for 100% of the time).
-  - Think about how to organize your day/work hours to best fit your life and maximize your focus.
-
+- **[Iterate](https://youtu.be/BW6TWwNZzIQ) your work.** Look for ways to make frequent, small changes. Get perspective on complex problems. There may be a simpler solution.
+- **Move quickly.** Aim to deliver results daily. "Everything is in draft." Resist gold-plating and avoid [bike-shedding](https://en.wikipedia.org/wiki/Law_of_triviality).
+- **Be efficient.** Focus on fewer tasks at one time. Use fewer words when possible. Go with "boring solutions." Keep things simple.
+- **Practice self-care.** Remember to take breaks. Schedule time off to recharge. Organize your workday to fit your lifestyle.
 
 ### 🔵 Objectivity
-<!-- TODO: write short preamble, like the others --> 
+Our objective as a company is to make money. This is how we measure success. Customers pay for products that make a difference. Approach every project with this in mind.
 
-- Make money
-   - There will always be a free, enterprise-friendly version of Fleet.  (Read Fleet's [commitment to open source stewardship](https://fleetdm.com/pricing).)
-   - But remember, [the goal](https://www.audible.com/pd/The-Goal-Audiobook/B00IFG88SM) of the company is to make money.
-   - This is how we measure success.
-- Be curious.
-  - Ask great questions & take the time to listen truly.
-  - Listen intently to feedback and genuinely try to understand (especially constructive criticism).  <!-- TODO: Trust the feedback from counterparts. It’s easy to quickly say “no” or ignore feedback because we’re busy and we often default to our way of thinking is right. Trust that your counterpart is making a good suggestion and give it the time/consideration it deserves. -->
-  - See failure as a beginning (it is rare to get things right the first time).
-  - Question yourself ("Why do I think this?").
-- Underpromise and overdeliver.
-  - Quality results often take longer than we anticipate.
-  - Be practical about your limits and about what's possible with the time and resources we have.
-  - Be thorough (don't settle for "the happy path"; every real-world edge case deserves handling).
-- Prioritize the truth (reality).
-  - Be wrong and show your work (it's better to make the right decision than it is to be right).
-  - Think "strong opinions, loosely held"  (proceed boldly, but change your mind in the face of new evidence)
-  - Avoid the sunk cost fallacy (getting attached to something just because you invested time working on it or came up with it).
-  - Be fair to competitors ("may the best product win.").
-  - Give credit where credit is due; don't show favoritism. <!-- as it breeds resentment, destroys employee morale, and creates disincentives for good performance.  Seek out ways to be fair to everyone - https://about.gitlab.com/handbook/values/#permission-to-play -->
-  - Hold facts, over commentary.
-- Be rigorous.
-  - Speak computer to computers. A lucky fix without understanding does more harm than good.
-  - When something isn't working, use the scientific method.
-  - Especially think like a computer when there is a bug, or when something is slow, or when a customer experiences a problem.
-  - Assume it's your fault.
-  - Assume nothing else.
+- **Be humble.** Seek feedback and understanding. Remember, it’s rare to get things right the first time. Question yourself.
+- **Underpromise and overdeliver.** Be practical about what's possible. But don’t settle for the “happy path” right away.
+- **Prioritize the truth.** Feel free to change your mind in the face of new evidence. Avoid the sunk cost fallacy. Give credit where credit is due.
+- **Be rigorous.** A lucky fix without understanding does more harm than good. When something isn't working, use the scientific method.
 
 ### 🟣 Openness
-<!-- TODO: preamble -->
+Openness leads to better products and stronger partnerships. Being open about your work isn’t always easy. But practicing this skill will help you throughout your career.
 
-- Anyone can contribute to Fleet.
-  - Be outsider-friendly, inclusive, and approachable.
-  - [Use small words](http://www.paulgraham.com/writing44.html), so readers understand more easily.
-  - Prioritize accessible terminology and simple explanations to provide value to the largest possible audience of users.
-  - Avoid acronyms and idioms which might not translate.
-  - Welcome contributions to your team's work from people inside or outside the company.
-  - Get comfortable letting others contribute to your domain.
-- Write everything down.
-  - Use the "handbook first" strategy.
-  - Writing your work down makes it real and allows others to read on their own time (and in their own timezone).
-  - Never stop consolidating and deduplicating content (gradually, consistently, bit by bit).
-- Embrace candor.
-  - Have "short toes," and don't be afraid of stepping on toes.
-  - Don't be afraid to speak up (ask questions, be direct, and interrupt).
-  - Give pointed and respectful feedback. <!-- (in the same way you would want to receive it) -->
-  - Take initiative in trying to improve things (no need to wait [for a consensus](https://twitter.com/ryanfalor/status/1182647229414166528?s=12)).
-  - Communicate openly (if you think you should send a message to communicate something, send it, but keep comments brief and relevant).
-  - Be positive, and assume positive intent.
-- Be transparent.
-  - Everything we do is "public by default."
-  - We build in the open.
-  - Declassify with care (easier to overlook confidential info when declassifying vs. when changing something that is already public from the get-go).
-  - [Open source is forever](https://twitter.com/mikermcneil/status/1476799587423772674).
+- **Welcome contributions.** Be friendly, inclusive, and approachable. Get comfortable letting others contribute to your domain.
+- **Embrace candor.** Be positive and assume positive intent. Don’t be afraid to speak up. Give pointed and respectful feedback. 
+- **Write everything down.** Let people learn about your work. Use simple language. Avoid acronyms and idioms that might not translate.
+- **Be transparent.** We build in the open. Everything we do is public by default. Declassify confidential information with care. 
 
 ## History
 

handbook/company/why-this-way.md

@@ -1,5 +1,31 @@
 # Why this way?
 
+## Why open source?
+
+### Benefits
+
+Open-source software development is easier than proprietary models. Instead of limiting input to a select group, we welcome contributions from a diverse community of passionate professionals. These unique perspectives help us test assumptions, overcome biases, and discover innovations faster than we would on our own.
+
+Here are the key benefits of open-source software development:
+
+- **Transparency.** Everyone has access to the source code, including executives, employees, and even end users. Anyone can confirm claims with first-hand evidence.   
+- **Modifiability.** Anybody can make improvements at any time. You can build on existing ideas or start something brand new. Every contribution benefits the project as a whole.
+- **Community.** Open-source contributors really care. They love solving problems and sharing solutions. As their careers grow, so does the community, which helps drive adoption.
+
+### Security
+
+So much visibility might make people nervous. But open-source projects have practices in place that encourage collaboration and promote security. Osquery uses configuration management, issue tracking, and code reviews as part of their development process. [Learn more about osquery’s security measures](https://github.com/osquery/osquery/blob/master/ASSURANCE.md#security-implemented-in-development-lifecycle-processes).
+
+We’ve adopted similar policies at Fleet. Anybody in our community can suggest changes, but only Fleeties with appropriate access can merge them.
+
+### Results 
+
+Open source isn’t just a development model. It’s a movement. It’s an effective, authentic way for individuals to achieve a common goal.
+
+Since 2020, Fleet has given visibility into over 1.65 million servers and workstations. Fortune 1000 companies like Uber, Atlassian, and [Wayfair](https://fleetdm.com/device-management/fleet-user-stories-wayfair) now have the insights they need to easily maintain continuous compliance.
+
+Our community made this happen. That includes feedback from our customers. Your suggestions directly shape [the direction of our product](https://fleetdm.com/pricing). After all, we’re here to help you.
+
 ## Why do we use a wireframe-first approach?
 
 Wireframing (or "drafting," as we often refer to it at Fleet) provides a clear overview of page layout, information architecture, user flow, and functionality. The wireframe-first approach extends beyond what users see on their screens. Wireframe-first is also excellent for drafting APIs, config settings, CLI options, and even business processes.